XFS check script on boot?
I've recently suffered an XFS corruption on a remote server (intel, debian etch, custom 2.6.X kernel): at some point some process hit an XFS inconsistency on /var, so /var desappear and suddenly machine refuse to work.
Being a remote machine with no full-knowledge people there, i've rebooted it, entered in ssh and stopped all services and tasks, arriving at the point where i can remount /var readonly.
So i was able to xfs_check the partition (that confirmed me the corruption), but i was not able to unmount /var, so i was forced to use '-d' options of xfs_repair. That indeed worked. ;)
This was the first tile i hit a xfs filesystem corruption, so i'm asking why seems there's no /etc/init.d/checkfs.sh-like script that check and repair XFS filesystem at boot.
Probably doing fully automatically it is a bit too dangerous, but an approach like 'normal' fsck, eg if filesystem are too corrupt (it need '-f' option) ask admin password and force to do it by hand, seems to me simple and effective.
Someone can explain me? Thanks.
Signature · 4 lines
dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) marco.gaiarin(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797
Quoted 3 lines · Marco Gaiarin
This was the first tile i hit a xfs filesystem corruption, so i'm asking why seems there's no
/etc/init.d/checkfs.sh-likescript that check and repair XFS filesystem at boot.
Because XFS is a journaling file system which can, and should, recover automatically from an unclean shutdown such as a system crash or power failure.
If you get XFS corruption after a reboot then you have a hardware or software problem that shouldn't be happening and which ought to be investigated and fixed.
The purpose of a journaling file system is to make time-consuming fsck and similar checks unnecessary after a reboot.
Mandi! Jason White
In chel di` si favelave...
Quoted 2 lines
The purpose of a journaling file system is to make time-consuming fsck and similar checks unnecessary after a reboot.
I know exactly that, and indeed, i agree.
I'm not speaking about writing a script that check everytime the filesystem, but sometime (triggered by /forcefsck?)
The problem arise when you have on a remote site people with low knowledge, and have to instruct them to run the kernel in init=/bin/bash mode or in initrd 'emergency' mode, spelling all command by phone.
[ok, a remote controlled KVM switch is on the buy list ;]
With a such boot script, if a fsck was forced, and a corruption founded, the system ask for root password and an operator find a shell with / mounted readonly and all other system unmounted (eg, the 'normal' way of checking eg, for EXT3; apart that for other filesystem a 'simple' check are ever tried, and password are asked only for serious corruption that need 'fsck -f').
A good starting point for trying a recovery.
Signature · 4 lines
dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) marco.gaiarin(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797