Linux e la scansione integrità dischi

[Lotharius]

Apro questo thread per sapere qualcosa circa la scansione integrità dei dischi su Linux. Dopo essermi sufficientemente documentato in giro per internet, ho deciso di effettuare una scansione approfondita di un hard disk esterno USB da 400Gb avente filesystem EXT3: ho connesso il disco, poi l'ho smontato tramite l'apposito comando presente nella utility Gestore dischi. Dopodichè ho avviato il terminale e ho lanciato il seguente comando:
sudo e2fsck -ccfktv -C 0 /dev/sdb1
la scansione si è avviata normalmente....

....dopo più di 12 ore la scansione è a questo punto:

e2fsck 1.41.11 (14-Mar-2010)
Ricerca dei blocchi non validi (test in moalità lettura-scrittura non distruttiva)
Controllo con un modello casuale: 69.77% done, 12:19:10 elapsed

Quello che vorrei sapere è: ma è normale che per effettuare un controllo completo dell'integrità al pari di come si fa in Windows con chkdsk C: /F /V /R si deve aspettare l'infinito? Io adesso non so se alla fine di questa scansione con "modello casuale" il programma continuerà con qualche altro tipo di verifica, però non oso pensare quanto impiegherebbe a verificare approfonditamente un hard disk da 3Tb! Dovrei lasciare il computer acceso un paio di mesi?!?
Come si fa ad effettuare una scansione che restituisca con certezza assoluta l'integrità fisica dei cluster del disco senza impiegare metà della propria vita?

[Lotharius]

Bene, sembra che la procedura di scansione sia finita. Di seguito riporto tutto ciò che riferisce il terminale:

e2fsck 1.41.11 (14-Mar-2010)
Ricerca dei blocchi non validi (test in moalità lettura-scrittura non distruttiva)
Controllo con un modello casuale: done
Hitachi400: Updating bad block inode.
Passo 1: Controllo di inode, blocco(i) e dimensioni
Passo 2: Analisi della struttura delle directory
Passo 3: Controllo della connettività di directory
Pass 4: Controllo del numero dei riferimenti
Pass 5: Checking gruppo summary information

Hitachi400: ***** IL FILESYSTEM E' STATO MODIFICATO *****

1918 inodes used (0.01%)
1042 non-contiguous files (54.3%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 1571/1472/30
87334350 blocks used (89.41%)
0 bad blocks
31 large files

1760 regular files
149 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
1909 files
Memory used: 356k/14912k (223k/134k), durata: 65240.24/134.98/25.74
I/O read: 6319MB, write: 1MB, rate: 0.10MB/s

A parte il fatto che il tutto abbia richiesto l'inaccettabile quantità di DICIOTTO, non riesco a capire se posso stare tranquillo o devo preoccuparmi: da una parte dice che non ci sono bad blocks, poi elenca dei "ind/dind/tind blocks" che non ho idea cosa siano, poi tutto in maiuscolo dice che il filsystem è stato modificato...
Chi mi illumina?

[Lotharius]

Beh, sono portato a credere che chi usa Linux non abbia mai fatto un controllo degli hard disk...

[Gimli[2BV!2B]]

Mai fatto così pesante.
Se il disco da segni di cedimento supportati da qualche indizio S.M.A.R.T. inizio a tenerlo d'occhio ed aumento i backup fino a che non lo pensiono.

Il fatto è che fargli fare una lavorata del genere non credo gli faccia bene e non mi è mai successo che le partizioni Linux manifestassero errori strambi come Win...

Ah, l'EXT3 non è adatto per volumi di grandi dimensioni: uno dei principali obiettivi dello sviluppo di EXT4 era di permettere controlli più efficienti con volumi dalle dimensioni attualmente diffuse.
Con EXT4 i tempi per un controllo standard sono stati ridotti di un ordine di grandezza.

Riguardo ai risultati non vedo niente di male, a quanto pare c'era un errore in un inode che è stato corretto, zero blocchi rovinati.

smartctl -a /dev/sdb riesce a leggere i registri del disco? Mi sembra di ricordare che riuscisse anche se collegati via USB (mi rendo conto ora che non uso più dischi USB da mesi se non anni...).

[Lotharius]

Questo hard disk è stato spedito tramite SDA, quindi ti lascio immaginare le "tranvate" che avrà preso nel trasporto Era obbligatorio fare un'analisi dell'integrità fisica del disco, a prescindere da quella del filesystem in se.
Purtroppo non lo posso partizionare in EXT4, perchè lo collego spesso anche al player multimediale (un Xtreamer) che legge e scrive su Ext3, ma non su Ext4.
Effettivamente anche io eviterei volentieri hard disk USB, però purtroppo è una scelta obbligata, visto che i NAS costano l'ira di dio e l'accesso tramite rete sui dati contenuti in un PC sono sempre altalenanti come troughput... l'hard disk USB bene o male fa il suo sporco lavoro e ti garantisce un uso "indolore".

Cosa mi consiglieresti di togliere dal comando quindi? Cioè da "sudo e2fsck -ccfktv -C 0" togliendo le due "c" elimino il controllo completo e quindi accelero molto la scansione; per quanto riguarda gli altri parametri, di cosa posso fare a meno senza sacrificare l'attendibilità della scansione?

[Gimli[2BV!2B]]

Scendendo a singola c si limita il controllo sui blocchi al solo test di lettura.
Togliendo entrambe le c si fa un controllo normale (k non viene considerata).
Le restanti opzioni sono cosmetiche (esclusa la f che forza il controllo a file system pulito).

Se con due c occorre un'era geologica puoi provare ad accontentarti di una sola, altre strade non ne conosco né leggo nulla di interessante nel man.

badblocks permette di fare i soli test delle c di e2fsck e non ha molte opzioni; l'unica che credo possa influenzare i tempi è questa:

-c number of blocks
              is the number of blocks which are tested at a time.
              The default is 64.

Però non ho idea se valori diversi dal default possano migliorare l'efficienza.

smartctl non fornisce alcuna informazione?

[Lotharius]

Allora, il comando smartctl non lo posso lanciare perchè stranamente non risultano installati gli smartmontools (mi consiglia infatti di installarli digitando il comando apt-get install smartmontools). La cosa strana è che il programma Gestione dischi include un campo di lettura dei dati SMART che mi restituisce i valori effettivi ad esempio dell'hard disk di sistema; si tratta di una funzione utilizzabile esclusivamente da Gestione dischi e non richiamabile da terminale?

Inoltre, ho riprovato ad effettuare una scansione digitando sudo e2fsck -ftv -C 0 /dev/sdb1 quindi togliendo solamente le due "c" ed il processo ha impiegato solamente un quarto d'ora, con il seguente risultato:

e2fsck 1.41.11 (14-Mar-2010)
Passo 1: Controllo di inode, blocco(i) e dimensioni
Passo 2: Analisi della struttura delle directory
Passo 3: Controllo della connettività di directory
Pass 4: Controllo del numero dei riferimenti
Pass 5: Checking gruppo summary information

1918 inodes used (0.01%)
1042 non-contiguous files (54.3%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 1571/1472/30
87334350 blocks used (89.41%)
0 bad blocks
31 large files

1760 regular files
149 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
1909 files
Memory used: 432k/14912k (223k/210k), durata: 847.32/134.50/26.67
I/O read: 6319MB, write: 1MB, rate: 7.46MB/s

Ora, non c'è una via di mezzo fra un controllo da 18 ore e uno da un quarto d'ora? Perchè quest'ultimo ha indubbiamente saltato l'analisi accurata dei cluster...

[Gimli[2BV!2B]]

Originariamente inviato da Lotharius

mi consiglia infatti di installarli digitando il comando apt-get install smartmontools

Ok, non puoi/vuoi installarli? Immagino che i dati della gestione dischi arrivino da una qualche libreria.

Con una sola c, per fare il test dei blocchi in sola lettura?
e2fsck -cftv -C 0 /dev/sdb1