Re: Skipping fsck during boot with systemd?
On 20141211_1332+0000, Brian wrote:
> On Wed 10 Dec 2014 at 14:22:59 -0700, Paul E Condon wrote:
> > On 20141210_1830+0000, Brian wrote:
> > > On Wed 10 Dec 2014 at 19:23:07 +0300, email@example.com wrote:
> > >
> > > > On 10/12/2014 14:04, Andrei POPESCU wrote:
> > > > >
> > > > >Of course, there's also the option of completely disabling automatic
> > > > >fsck (there are several ways to do this), as I understand is the default
> > > > >for new enough filesystems. This would make more sense for me on systems
> > > > >with bad power (you'd still get the "bad shutdown" check).
> > > >
> > > > Yes, disabling and doing manual checks from time to time is a
> > > > possibility, but you'd have to convince all users to hand their
> > > > gears to an admin outside of business hours. The said admin (who
> > > > might just bee a teacher in fact) might not be happy with the idea
> > > > of a week-end spent at fsck'ing the world out of the compulab, just
> > > > because of systemd. With the conditions I mentioned earlier running
> > > > a fsck regularly is a good thing, just not being able to interrupt
> > > > it in case of emergency isn't.
> > >
> > > Ever since Wheezy automatic fsck has been disabled on new installs. For
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Until I read the above, I had not realized that automatic fsck had
> > been gone for so long -- and without me noticing. I suppose it is
> > true, but I have no way of verifying. I know Wheezy and Jessie were
> > both new installs for me because I had a very poor track record of
> > doing successful dist-upgrades.
> This paragraph constitutes data. It says that you have gone without an
> fsck for x years without noticing anything untoward that you can ascribe
> to a lack of one. It may be less detailed than a dedicated study might
> want but they are valid data.
You assume too much. I did not say my system was utterly stable. In
fact, there was something seriously wrong that required me to
repeatedly re-install from backups. Only when I read your post did I
think that the maybe your claim of forced fsck being dropped might be
true. But as Bob Proulx said much better than I, we have no data. I
had so many occasions on which I needed to re-install that I developed
a semi-automated re-install procedure that works so nicely that I think
I will be using it instead of dist-upgrade in the future. It does get
rid of cruft on the disk.
> 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*
> > Of course, there might have been some disastrous loss of data out
> > there somewhere on someone else's computer. And that someone might not
> > have realized that his data might have been saved if there had been a
> > automatic fsck. If he thought about it at all, he probably just
> > supposed that the disk failed 'between file checks', which had always
> > been a possibility.
> These are also data. It is also conjecture. It is very doubtful that
> 10,000 or 100,000 similar accounts would see any useful conclusion
> > So the fact that there is no record of complaints
> > proves nothing, one way or the other. We have no valid data, IMHO.
> We have no data (valid or not) about failure. We do have data relating to
I reject the concept of invalid data.;-)
We do have some anecdotal information about user behavior, or about how
users write anecdotes. But users write in very different styles. It is,
IMHO, seldom true that an anecdote is worthy of careful textual analysis.
> success; you added to it above. :) One single, well-substantiated
No. See above augmentation of my account.
> failure would be enough to cause a conclusion drawn from the record of
> success to be re-examined.
I commend Bob for his clear statement of the objection to your reasoning.
Paul E Condon