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

Re: Skipping fsck during boot with systemd?

On Fri, 12 Dec 2014, 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 find "mount count" fs checks useless.  You have to shutdown your
system on a regular basis for it to be effective.  My personal desktop
system runs 24/7. I usually only shut it down 2 or 3 times a year.
For cleaning.  Guess I could set up "time between" checks, but
I prefer to manually fsck.  Easier.  I just do this as root before
shutdown -r now:

touch /forcefsck

On booting, fsck is run on all partitions, then the empty file
forcefsck is deleted. So, this only works for that particular boot.

I don't know how effective this check is though.  But I've NEVER had a
dirty partition reported in the past 8 years or so. The nice thing is it
is a very fast check. My 16GB / checked in less than 5 seconds, and the
205GB /home in about 10 seconds or so. (I didn't actually time this.
Subjective estimates.) However, it seemed TOO quick. Never thought
about that until today when I actually sat there and watched the whole
shutdown-reboot sequence. Usually I don't.

Running a very custom Wheezy 64-bit install: 3GHZ quad-core AMD Phenom,
8GB RAM, Openbox WM only with a single LXPanel.


Reply to: