[Nix-dev] Re: [Nix-commits] SVN commit: nix - 13932 - eelco - nixos/trunk/boot

[Eelco Dolstra]

Hi,

Ludovic Courtès wrote:

>> +    # For unclean ext3 file systems, fsck.ext3 should just replay the
>> +    # journal and exit, but in practice this takes *much* longer than
>> +    # letting the kernel recover the FS.  So, don't run fsck on
>> +    # journalling file systems.
>> +    eval $(fstype "$device")
>> +    if test "$FSTYPE" = ext3 -o "$FSTYPE" = ext4 -o "$FSTYPE" = reiserfs -o "$FSTYPE" = xfs -o "$FSTYPE" = jfs; then
>> +        return 0;
>> +    fi
> 
> Just because recovery can be performed pretty fast doesn't mean `fsck'
> should *never* be run.  It's still recommended, AFAIUI, to run it from
> time to time.  My understanding of your patch is that it will just never
> be run, leaving no chance to detect (and repair) inconsistencies that
> could otherwise go undetected for long periods of time.

Good point.  On the other hand, fsck always decides at an inconvenient time that
it has to check your whole file system right now :-)  For instance, if you
reboot a server just once a year or so, then fsck will basically always run, so
a reboot that should be fast will instead take a very long time...

Still, I'd like to run fsck always, but it just takes a painfully long time on
ext3 filesystems that haven't been shutdown cleanly.  Like several minutes on my
laptop.  This kind of defeats the purpose of a journalling file system :-)
Strangely, the e2fsck manpage says:

"After the journal has been applied, a filesystem will normally be marked as
clean.  Hence,  for  ext3  filesystems, e2fsck will normally run the journal and
exit, unless its superblock indicates that further checking is required."

but this is not how it actually appears to behave...

-- 
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/