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.
B
Reply to: