Re: Skipping fsck during boot with systemd?
On 12/10/2014 10:14 AM, Andrei POPESCU wrote:
In my not so humble opinion, one should be using such a switch to
re-examine one's setup, practices, etc. You might discover some
"interesting" stuff. As far as I'm concerned:
1. I'll be looking into disabling periodic checks on all my ext4
partitions, in line with the not so new mkfs defaults.
2. As has been pointed out in this thread, interrupting or completely
skipping the check after unclean umount is *dangerous* and can lead to
data loss. If you get one of these while you're on battery power it's
probably a good time to think if your backup strategy is good enough.
3. If one can afford the additional downtime a full fsck as part of
regular maintenance *might* make sense. E.g. I could imagine on kernel
upgrades (which force a reboot anyway) one boots up with the new kernel,
check everything is working fine and then reboots a second time with
 the only other filesystem I'm (still) using is xfs, which doesn't do
 and start praying if it isn't
I'm posing a question at this point because it relates directly to your
post excerpted above. If you feel this is off-topic for this thread,
I'll be glad to start a new thread.
I came to the same conclusions you outlined and implemented 1 and 3
among your suggestions on my home systems -- all running testing.
However, I've been helping a few remote users of Debian testing -- some
of them thousands of miles from me -- by doing updates/upgrades,
configuration changes as needed, and so on for them.
Using fsck.mode=force on the linux command line works fine for the
purpose of forcing a file system check at home, but I don't see a
practical way to use it on the remote systems. Do I really have to walk
each of them through editing of the linux command line or through
alteration of their grub menu, etc. so they can initiate fsck manually
themselves at boot time once-in-a-while? Or can you think of a way I can
be in control of this without bothering them? Some of these folks would
not be good candidates for performing these changes to such essential
parts of their systems.
At present I can still use "touch /forcefsck", but I see the warning
about this in the log, and I imagine the ability to use this command to
cause an fsck to run during the next reboot may cease to be implemented
at some point.
This issue -- while not what I'd call a bug -- is a feature difference
that may eventually result in my having to stop performing this
particular part of the maintenance. This is of some concern to me, most
particularly in regard to the older systems which use ext3.