Re: [RiminiLUG-General] Re: log per il mount

[Daniele Palumbo <daniele@xxxxxxxxxxxx>]

On 10/12/2010 15:59, Massimo Gengarelli wrote:
> On Fri, 10 Dec 2010 15:48:03 +0100 Daniele Palumbo
> <daniele@xxxxxxxxxxxx>  wrote:
> > in ogni caso, a prescindere, mi torno a ripetere, se nel manuale ti
> > dicono di mettere 2 per le altre partizioni non vedo perché non devi
> > farlo :)
> In realtà nel manuale non dicono di mettere 2, ma di mettere 2 o 0.

"The root filesystem should be specified with a fs_passno of 1, and 
other filesystems should have a fs_passno of 2."

Non vedo alcuno 0...

> 0
> significa semplicemente che non vuoi che in fase di init fsck controlli
> se quel filesystem ha bisogno di essere controllato. Generalmente per i
> filesystem ext[2-4] puoi "forzare" il controllo o vedere quando verrà
> controllato utilizzando tune2fs (o qualcosa del genere, sto andando a
> memoria),

e2fsck, per ext2/3/4.

> con altri fs non saprei,

reiserfsck, ad esempio, in ogni caso viene lanciato il comando fsck che 
fa da wrapper ed identifica la partizione, lanciando il "giusto" fsck.

sono presenti molti symlink/hardlink in tutte le distribuzioni che ho 
visto fino ad oggi (e quindi presumo in tutte quelle esistenti), che si 
chiamano fsck.[tipopartizione], quindi fsck.ext3, fsck.ext4, 
fsck.reiserfs, fsck.vfat, ...

> mi sa che controlla semplicemente la
> tabella e vede se ci sono degli errori che debbano essere corretti.

fsck(8)
       The exit code returned by fsck is the sum of the following 
conditions:
            0    - No errors
            1    - File system errors corrected
            2    - System should be rebooted
            4    - File system errors left uncorrected
            8    - Operational error
            16   - Usage or syntax error
            32   - Fsck canceled by user request
            128  - Shared library error

guardare anche l'opzione "-A".


> Nel caso di Roberto credo sia meglio che tenga a 0, dato che la
> partizione che va a montare è in realtà un'immagine di loopback, e
> rischierebbe di rallentarsi il boot inutilmente.
> Piuttosto io farei un fsck a manina ogni qual volta *sai* che
> potrebbero esserci degli errori (hai tirato giù la macchina virtuale
> che non era in modalità snapshot).

Se una partizione ha dei problemi, e adesso parlo di ext3, fsck ritorna 
un valore >0, che vuole appunto dire "ha dei problemi".
Quindi, ne viene impedito il mount (almeno, viene impedito in rw, 
tipicamente debian la monta in ro).

http://www.mjmwired.net/kernel/Documentation/filesystems/ext3.txt
"norecovery/noload: Don't load the journal on mounting. Note that this 
forces mount of inconsistent filesystem, which can lead to various 
problems."

Detto anche, se una partizione ha dei problemi, risolvili altrimenti 
"soffrirai molto"(tm).

Se il check non è necessario/possibile, perché il tipo di partizione non 
lo prevede, lo stesso fsck.X (nel nostro caso fsck.vboxfs) ritornerà 
sempre un valore congruo per continuare il boot (non ho sotto mano il man).

Fare il check a mano, personalmente, lo vedo sempre come ultima 
spiaggia... Le cose "a mano" di default diventano "non le fai mai 
neanche quando servono o comunque hai il sistema incristato e moccoli"...
almeno questo per esperienza personale.

> Per quanto riguarda invece l'altro campo (non so se era già stata data
> una risposta) è un campo che sta lì solo per motivi storici, e si
> chiama "dump", serve per determinare se quel filesystem debba essere
> backuppato o meno utilizzando il comando dump (8).

no, non era stato analizzato.
come hai detto sta andando in disuso.

bye
d.