[systemd-devel] Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system

[Colin Guthrie]

'Twas brillig, and Reindl Harald at 16/08/13 10:50 did gyre and gimble:
> Am 16.08.2013 11:13, schrieb Colin Guthrie:
>> If I suspect my root partition has corruption and I want to do an fsck,
>> the first thing I'll do is remount it ro, as fast as I possibly can
> 
> and BTW if i suspect corruption on a datadisk which is used
> by a ton of services which makes it hard to unmount and fsck
> because it takes much longer than "touch /forcefsck; reboot"
> it does not matter what i write on the rootfs
> 
> in this case i want a as fast as possible way to do what i want to do

If I suspect corruption, I'm not going to reboot which causes a lot of
disk activity. I'd remount it readonly, (not unmount) to prevent any
further writes: "mount -o remount,ro /"

I accept that some state info will be lost and others may be in an
invalid state but that's probably preferable to the alternative.

To teach people to do "touch /forcefsck; reboot" if they suspect
corruption is a really, really bad idea IMO.


>> And besides, if you did write the config, why would you want to "prevent
>> on the next boot an unintended fsck"... surely the whole point in
>> writing the config is that it was an *intended* fsck, not an unintended one?
> 
> you missed the "after pass"

Yes, but you neglected to quote the bit I wrote after that which dealt
with that case too.

>>> nor do you want to struggle with
>>> the boot-menu on remote-machines
>>
>> Fair enough, but lots of remote machines have consoles that let you pick
>> even the boot options these days. It's not that crazy.
> 
> and lots of simple setups are not that perfect IT with
> firewalls in front of them - hnece the linux machine may
> be the firewall an dyou do not want ILO on WAN

Yes indeed. In which case you use some form of "one time boot" argument
system.

It's kinda a pointless argument tho'. I mean if you have corruption do
you just want to blindly accept all fixups the fsck suggests? If you do
not have a terminal to see the state of the corruption, or you cannot
control what is and is not fixed, then running a remote, blind fsck is a
pretty bad idea. Sure in the very simple case it might work, but are you
seriously suggesting that fsck's should be always be non-interactive
too? The argument somewhat breaks down if the system will go into
emergency mode to repair the corruption and you do not have console access.

>> If I suspect my root partition has corruption and I want to do an fsck,
>> the first thing I'll do is remount it ro, as fast as I possibly can. The
>> *last* thing I want to do is write more data to it potentially making
>> any corruption worse.
> 
> and if i am on a virtual machine the first thing i do is make a snapshot
> including the current RAM, type "touch /forcefsck" and look what happens
> and if it's no good i restore the snapshot

Sure. And if I'm making a cup of tea I'll probably boil a kettle. I'm
not sure where the VM part actually comes into this argument...

Yes, snapshots make sense generally, but then I would still want to do a
ro remount ASAFP and not touch a file in the filesystem. The snapshot
lets you not make such a mistake in a replay but that doesn't give any
merit to the general approach in the first place.

>> Having a file to trigger the fsck on the same filesystem I want to check
>> is braindead. A kernel command line arg is a much safer and more
>> sensible approach.
> 
> see above, form the in summary 40 Fedora setups including testing-machines
> there are exactly 6 physical and the rest is virtualized

This is no reason to favour this approach - the same potential for
corruption still exists. Virtualisation makes no difference here.

>> So no, it's not pointless and it's not useless
> 
> my problem with such deprecations is that systemd-guys tend to remove
> things sooner or later and there are *a lot* of good reasons as explained

The file-based approach is still supported. This warning has been here
for years.

If you want to complain, then do so when the support is eventually
removed. Right now it is offering best-practice, safety first advice. I
really cannot see how someone could have a problem with this approach
which offers the least chance of permanent damage.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/