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

Re: Skipping fsck during boot with systemd?

On 12/12/2014 6:47 PM, Brian wrote:
> 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?

I guess this is something Windows does better than Linux.  Windows never
does a checkdsk except after a hard crash - and not always then.


Reply to: