Prima di toccare il disco: identifica con precisione il device
Formattare un disco su Linux non è un’operazione “clicca e via”: il punto critico è scegliere il device giusto. Un errore qui significa perdita dati immediata. La regola operativa è semplice: prima identifichi il disco, poi verifichi che non sia quello di sistema, solo dopo procedi con partizioni e filesystem.
Se il disco è nuovo, non inizializzato, o sostituisce un supporto guasto, il flusso corretto è: riconoscimento del device, eventuale pulizia delle firme residue, creazione della tabella partizioni, creazione del filesystem, montaggio e persistenza in /etc/fstab. Se invece il disco contiene dati da preservare, fermati: questa guida non è per migrazioni “in-place”.
Una verifica minima da fare subito è questa:
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL
Qui vuoi vedere il disco corretto, senza ambiguità. Se il device è /dev/sdb, /dev/nvme1n1 o simili, annotalo con attenzione. Non fidarti solo della dimensione: controlla anche modello e seriale.
Step 1: conferma che il disco sia libero e non montato
La prima verifica operativa è capire se il disco è già usato. Un filesystem montato o una partizione in uso non va formattata “a mano” senza un piano di dismissione. Il comando più utile è lsblk, ma conviene affiancarlo a blkid e, se serve, a mount.
lsblk -f
blkid
mount | grep -E '/dev/sd|/dev/nvme'
Se il disco compare con un MOUNTPOINT, devi smontarlo prima di procedere. Se invece compare con un filesystem già presente ma non montato, significa che contiene una firma residua: puoi decidere se riutilizzarlo o ripulirlo in modo esplicito.
Per un disco davvero nuovo, spesso non vedrai nulla in blkid. È una buona notizia: vuol dire che non c’è una firma filesystem già registrata.
Step 2: pulizia delle firme residue quando il supporto è stato riutilizzato
Se il disco proviene da un vecchio server, da un array dismesso o da un ambiente di test, può contenere metadati di filesystem, LVM o RAID. In questi casi è utile rimuovere le firme prima di creare la nuova struttura. Questa operazione va fatta solo sul device corretto e solo se hai confermato che non contiene dati da conservare.
Il comando più diretto è wipefs, che mostra le firme presenti e consente la rimozione mirata. Prima fai una scansione, poi, se necessario, esegui la pulizia.
wipefs -n /dev/sdb
wipefs -a /dev/sdb
Il primo comando non modifica nulla: elenca le firme trovate. Il secondo le cancella. Se stai operando su un disco intero, non su una partizione, usa il path del device completo. Dopo la pulizia, ricontrolla con lsblk -f o blkid per confermare che il supporto risulti vuoto.
In ambienti con LVM o mdadm, può essere utile anche verificare se il kernel ha ancora metadata storici agganciati al device. Se vedi residui strani in lsblk, il problema non è il filesystem ma la stratificazione precedente del disco.
Step 3: scegli tra disco intero, partizione singola o schema più articolato
Qui non c’è una risposta unica. Se il disco serve per un uso semplice, come storage dati o backup locale, una singola partizione che occupa tutto il disco è spesso la soluzione più pulita. Se invece prevedi crescita, separazione tra dati e log, o compatibilità con strumenti legacy, può avere senso creare più partizioni.
Per la maggior parte dei casi operativi su Linux moderno, la scelta pratica è una tabella GPT con una partizione unica per i dati. GPT è preferibile a MBR su dischi grandi e in contesti recenti. Se il disco è destinato a boot UEFI, il discorso cambia e devi prevedere anche una partizione EFI; questa guida qui non entra nel boot disk di sistema, ma in un disco dati o secondario.
Se il supporto è già stato inizializzato con uno schema errato, puoi ricrearlo. Attenzione però: la ricreazione della tabella partizioni distrugge la struttura precedente.
Step 4: crea la tabella partizioni con GPT
Con parted puoi creare una tabella GPT in modo diretto. È uno strumento comodo perché parla bene con dischi moderni e rende chiaro il layout creato. Prima di lanciarlo, assicurati di avere il device corretto. Il rischio qui è totale sul disco scelto.
parted /dev/sdb --script mklabel gpt
Se vuoi una singola partizione che occupi tutto il disco, puoi creare anche quella subito dopo:
parted /dev/sdb --script mkpart primary ext4 0% 100%
Su dischi NVMe il nome del device cambia, ad esempio /dev/nvme1n1. La partizione risultante sarà /dev/nvme1n1p1, non /dev/nvme1n11. È un dettaglio banale solo finché non ci sbagli e formatti il target sbagliato.
Dopo la creazione, verifica il layout:
parted /dev/sdb print
lsblk /dev/sdb
Se vedi la partizione con la dimensione attesa, puoi passare al filesystem. Se invece il disco non mostra il nuovo layout, aggiorna la tabella partizioni del kernel con partprobe o stacca e riattacca il device in ambienti virtualizzati.
Step 5: crea il filesystem giusto per il caso d’uso
La scelta del filesystem non è decorativa. Per un disco dati generico, ext4 resta la scelta più semplice e prevedibile. Per carichi con esigenze specifiche puoi valutare xfs, ma non c’è bisogno di complicare se non hai un motivo concreto. La scelta va fatta in base al tipo di I/O, al tooling disponibile e alla modalità di recupero che vuoi tenere a disposizione.
Per ext4:
mkfs.ext4 -L dati /dev/sdb1
Per xfs:
mkfs.xfs -L dati /dev/sdb1
L’etichetta -L è utile perché ti permette di riconoscere il filesystem anche se il device cambia nome. In ambienti con più dischi uguali, questa è una scorciatoia concreta per ridurre errori operativi.
Dopo la formattazione, controlla la firma creata:
blkid /dev/sdb1
lsblk -f /dev/sdb
Devi vedere il tipo filesystem corretto e, se hai usato l’etichetta, anche il campo LABEL. Se il comando non restituisce nulla, qualcosa non è andato a buon fine oppure stai interrogando il device sbagliato.
Step 6: monta il filesystem in un punto coerente
Un disco formattato ma non montato non serve a nulla. Scegli un mountpoint leggibile e stabile, ad esempio /data o /srv/storage, in base al ruolo del volume. Evita percorsi casuali o temporanei se il filesystem deve durare nel tempo.
mkdir -p /data
mount /dev/sdb1 /data
findmnt /data
findmnt è più utile di un semplice mount perché ti mostra in modo pulito source, target e opzioni. A questo punto crea un file di prova per verificare scrittura e lettura:
echo test > /data/.write-test
cat /data/.write-test
Se il test fallisce, non andare oltre: prima risolvi permessi, mount readonly, errori filesystem o problemi di backend storage. Un mount apparentemente riuscito non garantisce che il supporto sia realmente scrivibile.
Step 7: rendi il mount persistente con /etc/fstab
Se il disco deve montarsi a ogni riavvio, non usare il nome del device come riferimento fisso. Il naming può cambiare, specialmente con SATA hotplug, NVMe o ambienti virtualizzati. Usa meglio UUID o label.
Recupera l’UUID con:
blkid /dev/sdb1
Il risultato sarà simile a UUID=
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.