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.
http://git.whamcloud.com/?p=tools/e2fsprogs.git;a=commit;h=3daf592646b668133079e2200c1e776085f2ffaf
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
reconciled?
Reply to: