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

Re: Skipping fsck during boot with systemd?

On Thu 11 Dec 2014 at 22:04:56 -0700, Paul E Condon wrote:

> On 20141211_1332+0000, Brian wrote:
> > 
> > Multiply your experience by 10,000 or 100,000 similar accounts and a
> > picture begins to emerge and you can decide on how much confidence you
> > can place in a conclusion based on the accumulated data.
> I did not contribute data to a growing pool of data on this situation,
> and a billion similar accounts from other users is ( 0 * 0 == 0 ) *no*
> data.

You have a very strange idea of what constitutes data. Here are some
more data (or non-data if you prefer :) ),

tune2fs(8) says

   You should strongly consider the consequences of disabling
   mount-count-dependent checking entirely. Bad disk drives, cables,
   memory, and kernel bugs could all corrupt a filesystem without
   marking the filesystem dirty or in error. If you are using
   journaling on your filesystem, your filesystem will never be
   marked dirty, so it will not normally be checked.  A filesystem
   error detected by the kernel will still force an fsck on the
   next reboot, but it may already be too late to prevent data loss
   at that point.

Very clear; mount-count dependent (or time-dependent) checking is
optional - but if you neglect doing it you run the risk of data loss.

The changelog for e2fsprogs has

   Mke2fs will now create file systems that enable user namespace
   extended attributes and with time- and mount count-based file
   system checks disabled.

This is very clear too; the standard e2fsprogs doesn't give you what it
strongly advises in tune2fs(8). The reason for the change in e2fsprogs
is that time- and mount count-based checks are not particularly useful.


If the checks are not useful, why do them? Most Debian users with new
Wheezy or testing installs won't be doing them as a matter of course
anyway and their number will grow in the coming years.

Are they any the worse off because these checks are not being made?
Has upstream got it wrong? Should some sections of the documentation
be rewritten? Or can default program behaviour and documentation be

Reply to: