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

Re: Skipping fsck during boot with systemd?



Le Wednesday 10 December 2014 09:49:51, Gian Uberto Lauri a écrit :
> Frédéric Marchal writes:
>  > Le Wednesday 10 December 2014 08:05:49, tv.debian@googlemail.com a écrit 
:
>  > > On 10/12/2014 09:30, Frédéric Marchal wrote:
>  > > > Le Tuesday 09 December 2014 16:36:53, The Wanderer a écrit :
>  > > >> On 12/09/2014 at 10:09 AM, Chris Bannister wrote:
>  > > >>> On Tue, Dec 09, 2014 at 09:48:58AM +0100, Frédéric Marchal wrote:
>  > > >>>> Now, is it possible to run fsck during shutdown? Users have been
>  > > >>>> asking for this for at least 10 years. Is it now acceptable,
>  > > >>>> possible, tolerated?
>  > > > 
>  > > > 2) is it wise to run fsck at that time? I have seen strong
>  > > > opposition in
> 
> Usually on shutdown you run sync that flushes the cache to the disk,
> cleanly preparing the disk for unmounting. The mount command should
> 'run' sync automatically when unmounting.
> 
> 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 from an 
unclean shutdown?

To my understanding, errors creeping into the file system are unavoidable in 
the real world, even without serious system crashes.

On the computer I'm using here (Debian Wheezy), automatic fsck at boot has 
been disabled from the beginning. At this time, the root partition has been 
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 errors 
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 system 
check?

Maybe I don't understand what fsck at boot is meant to fix then…


> fsck may take time. Relax, it needs that time.
>
> "The bearing of a child takes nine months, no matter how many women
> are assigned." ["The Mythical Man-Month", Frederick P. Brooks, Jr.]
> 
> "Ghe voe tempo, se speta" ["it takes time, just wait", old Venice
> saying]

I understand all these. The question here is about controlling when this time 
is taken and postpone the routine deep check a bit when it is inconvenient to 
do it during this particular boot sequence.

Unless, of course, someone says that the small errors creeping into the file 
system are not meant to be fixed at boot time. In that case, I'll ask what is 
the correct procedure to fix them.

Frederic



Reply to: