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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
