Re: Skipping fsck during boot with systemd?
On Wed 10 Dec 2014 at 13:30:22 -0700, Bob Proulx wrote:
> Brian wrote:
> > Ever since Wheezy automatic fsck has been disabled on new installs. For
> > the vast majority of users this passed unnoticed and for at least two
> > years most new users have never seen an enforced fsck at boot. During
> > the same amount of time there has not been a single report of any
> > adverse effect due to this default; no one has suffered and no file
> > systems have been harmed.
> >
> > I think we can conclude it is a safe default.
>
> I disagree. Two years is a very short time for this type study. I am
> shocked you would think it is a long time. Especially a study that
> isn't actively collecting any data.
There was a change to the default way a file system was made. The past
two years have brought no complaints, with or without a ^C being
capable of being used to stop a fsck. A research programme would likely
take this into account.
> How do you know there hasn't been any problems?
Bug reports; comments in user lists and forums, lack of action by the
fsckprogs package maintainer etc.
> How many people who
> had problems would even report it? Who knows? That data isn't being
> collected. The problem could easily be confounded with disk errors.
> If someone were to have a problematic system they would probably just
> end up installing over again, restoring from backup, and simply
> writing it off as a bad event they don't want to think about anymore
> without making any reports.
Low level degradation is very hard to detect and, when found, analyse.
Even so, one might expect it to appear over two years when tens of
thousands of machines are involved. People do notice things and are
given to making comments and reports. sometimes with conjecture and
sometimes with enough data to make it worth pursuing the lead.
> The lack of a routine fsck may be a safe default. Or it may not be.
The fact is that many, many Debian users do not experience a routine
fsck at boot time now and will not experience one in the future, They
will be unaware that the decision (rightly or wrongly) has been made for
them. There is no evidence for any adverse effects due to not having
time-based or mount-based checks.
> There isn't any data to say one way or the other. Certainly it is
> incorrect to say from any current data one way or the other. It is
> simply a judgement call from the local admin as to whether they think
> it is better to periodically fsck or not.
>
> I do know that when I fsck my server grade systems the fsck does make
> file system corrections during fsck time. Would any of those
> eventually grow to be serious? Don't know. Would the file system
> just collect mostly harmless lint over a decade? Maybe. Maybe it
> wouldn't matter. Or just maybe one of those errors would cascade into
> something more serious such as a data loss event. All we know is that
> periodic fsck runs do make file system corrections even on good
> quality systems with full ECC throughout. That tells me that when
> dealing with terabytes of data in file systems that errors do tend to
> creep into them.
>
> I will be continuing to fsck my systems periodically for the same
> reason that I reboot my systems periodically. Sure I know systems
> still running after years of uptime. But it isn't an uptime race.
> The goal for me is predictable reliability. Uncertainties get in the
> way of that goal.
Please note that I was not arguing against a periodic fsck mandated by
tune2fs or organised by the administrator. However, an interesting
question is whether the default mke2fs.conf benefits desktop and server
users equally well. If it does, the relevance of having a ^C at boot
time for stopping an fsck might be open to examination.
Reply to: