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

[Reindl Harald]

Am 16.08.2013 12:21, schrieb 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 /"

why should i remount the rootfs RO "if i suspect corruption on a datadisk"?

> 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.

nobody teaches anybody, you want to teach me while i know what i am doing

>>> 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.

aka "touch /forcefsck; reboot"

> 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?

damned *yes* because i am not that arrogant that i serious
believe knowing more about the FS than fsck

> 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

it does not matter if the idea is brilliant
there are situations where you have not much to choose

> 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" and "when" is nice and sometimes true
if whatever happens i have to deal with it

so waht - if the machine is 300 miles away and has only
SSH access i have not much options to choose

>>> 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...

where the VM part comes into this argument?
that this warning try to teach my on my VM's what i have to do maybe a reason?

> 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.

on a testing-VM with backups and snapshots please let it be
my problem what i want and stop to teach me while knwoing
what i am doing with pointless messages from the system

>>> 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.

*it makes* a difference

hence, on most of the machines i can take the risk because they
offer no public servcies, are mostly backup/replication clones
of production servers or testing-installations at all and so
*if* the fsck this way would fuckup the FS -> no problem

* revert to last snapshot
* doing the other way

and with more than 10 years expierience 1 out of 5000 cases
would go worng while the other 4999 are fine with /forcefsck

>>> 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

after it is removed it is *too late* to complain

systemd-developers so far never reverted anything after go-ahead and believe
whatever solution for whatever problem is better than before

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130816/239a2446/attachment.pgp>