[systemd-devel] Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system
Colin Guthrie
gmane at colin.guthr.ie
Fri Aug 16 05:05:35 PDT 2013
'Twas brillig, and Reindl Harald at 16/08/13 11:35 did gyre and gimble:
>
> 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"?
Oh come on! Seriously? Read between the lines and don't be so
deliberately pedantic. I'm not going to bother replying if you cannot
interpret a simple command to whatever disk layout you want to concoct.
If you're suggesting that using the /forcefsck file is safe for when you
want to force it on a different (i.e. data) partition, then I'd say
you're correct, but if you're suggesting teaching users different
methods depending on whether the partition where corruption is suspected
is the root or a data partition then I'd suggest that's a bad idea.
Teach them one method that works for all circumstances.
>> 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
Erm, so when all the current bread of users die, no one will know how to
use a computer? Come on! People learn stuff all the time, documentation
teaches people how to work and how to do things and the way you want to
work *still works* and yet you still feel the need to complain and
create examples where everything fails in just right way to justify your
preferred approach and yet cannot really justify it when it fails in a
less than perfect way (which failures have a habit of 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"
No. It's not aka at all. It's something in the bootloader which may
store it's configuration totally outside of the filesystem or disk in
e.g. EFI vars or on a separate, small /boot partition.
And again, if you like doing it via this way *it still works!* All you
get is a log message. Is it really that offensive to you?
> after it is removed it is *too late* to complain
git revert. It's never too late to complain. If you have valid arguments
they will be listened to. So far, however, you've not given any
arguments that are (IMO at least) valid. Others may disagree of course.
Quite frankly, this entire thread is about a log message. So far you've
created contrived examples to show failures in just the right way to
justify your opinion and you've even quoted examples where you admit it
could help to do it the recommended way.
I'm not going to bother discussing this any longer as you're clearly not
going to change your mind. We'll just have to agree to disagree - and
that's not a bad thing. There are probably several points in systemd I
disagree with, but they are small and relatively trivial.... in this
case it's just a bloody log message!
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/
More information about the systemd-devel
mailing list