[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Purpose of fsck at boot (was: Skipping fsck during boot with systemd?)

On 12/10/14, 3:41 AM, "Frédéric Marchal"
<frederic.marchal@wowtechnology.com> wrote:

>Le Wednesday 10 December 2014 11:10:52, Frédéric Marchal a écrit :
>> Le Wednesday 10 December 2014 09:49:51, Gian Uberto Lauri a écrit :
>> > You run fsck on power up because the 'system does not remember' if it
>> > was shut-off cleanly or not. If the disks are clean and the last check
>> > is not too old, fsck just report this and does nothing. Else it takes
>> > care of the safety of your data.
>> Are you implying that the only purpose of fsck at boot is to recover
>> an unclean shutdown?
>> To my understanding, errors creeping into the file system are
>> in the real world, even without serious system crashes.
>> On the computer I'm using here (Debian Wheezy), automatic fsck at boot
>> been disabled from the beginning. At this time, the root partition has
>> mounted 249 times since the last check. Presumably, fsck assumed, from a
>> casual glance at boot time, that there was nothing to fix.
>> Yet, running e2fsck -n -f /dev/disk/by-uuid/whatever reports several
>> such as orphaned inode list, block bitmap differences, wrong free blocks
>> count, inode bitmap differences, wrong free inodes count.
>> Are these errors not supposed to be fixed by a periodic deeper file
>> check?
>Following this post, I restarted the computer in single user mode. I had
>ifdown eth0 before I could mount -o remount,ro /dev/sda3 but then I could
>e2fsck -f /dev/sda3 on the boot/root partition.
>And surprise! No error at all!
>I restarted the computer in normal mode and, for sure, e2fsck -n -f
>reports the same errors as above.
>Is it an artifact induced by the ext4 journal?

I don't think so, I expect it is an "artifact" of a running, dynamic, in
use file system.

There will be 'cached' data in RAM OR in the journal that is more recent
and up to date than data stored on the hard disk.

The fsck programs all operate on hard disk storage, not cache or journal,
so they will report inconsistencies on a read/write file system because
some portions of disk storage will be out of sync with respect to other

When you boot a system, fsck is run while the root file system is mounted
read only, just as when you did the re-mount in single user mode.  The
disk data is fully up to date and hence no errors are reported.

By the way, there may be some confusion over the '-n' option.  This makes
e2fsck operate in "read only" mode, but the file system itself may be
read/write.  You only get a read-only file system when it is explicitly
mounted read-only.

You are probably aware of this, but I wanted to make it clear, for others
reading this.


Reply to: