Dr. Werner Fink wrote:
---- The most optimal way for deficient file systems that need fsck is likely to use an initrd if it is needed that often. The alternative is to pick an advanced journaling file system rather than a modern one that, for me, has only needed a real 'fsck', only *once* in the past 12 years of constant usage.
In other words: as this had worked for you the last 12 years due luck you want that all other users may risk data loose?
Luck has nothing to do with it. It was my cross-circuiting to B...er, Ask the xfs people about reliability stats. Real corporations have a very low failure rate with XFS -- as they run with UPS's and stable kernels. Unexpected crashes and and power interruptions are things that XFS doesn't deal well with, but if one has a stable kernel and power supply, there is no luck involved. If you don't have those, then I'll grant it isn't as reliable, and prebooting from an initrd might be a better choice -- if the init rd has utils to recover from problems (unlike OpenSuse's)...
For one -- if your root FS is small, you are less likely to corrupt it. Two -- the whole point of a journalling FS is to not need a full FSCK -- even NTFS from MS doesn't need booting from an initrd -- only RARELY does it need an offline check -- maybe once every 5 months -- and it has EVERYTHING on it's root FS (the entire OS and all programs (it's 1 partition because that's the only partition that gets completely backed up during backup). But xfs -- 1 time in the past 12 years I've needed to do an xfs_repair on a root file system.
Even xfs used with journaling enabled should not be checked/repaired if mounted even if mounted only ro. From xfs_repair(8) --
---- This is perfect. Those utils are not only not used or called during boot -- but they aren't even on the initrd. They never have been because there is no need for them. What you do have is a shell script: ****IS**** the point. Those are NOT fsck.xfs. Those are *exceptional measures*. Suse doesn't call xfs_repair or xfs_check on each boot, because XFS doesn't need it and it isn't recommended. Suse calls a lame fsck that's a *SHELL* script that checks to see if the device is mounted. You can't quote manpage info for something other than xfs.fsck -- and for that there is no requirement it be mounted R/O, -- just that it be mounted AT ALL, since that is the only test in the script: /tmp/initrd/usr/sbin# more fsck.xfs #!/bin/sh -f # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved. ... while getopts ":aApy" c ... if [ ! -e $DEV ]; then echo "$0: $DEV does not exist" exit 8 fi ... exit 0 ------------- There is nothing the above does for anyone if it is run from root and checking root. Even if it is run from initrd, it doesn't do anything useful. The system won't boot, and you won't be able to repair it because the initrd doesn't contain a rescue disk -- that's a separate item.
To require to spend extra time and space for something that happens once in a Jovian year, is not logical. For any professional use it is a inalienable requirement to minimize the risk of data loose.
Right... so UPS/ stable kernel and XFS... But OSuse's initrd doesn't have any tools to check an xfs root file system -- because it isn't needed. That's the official view of 20-years of industry experience with XFS -- NOT my experience.. Your entire point is moot, as SuSE's initrd has no tools to repair the file system. That's when you bring out a rescue DVD or USB-key -- initrd has nothing for that. But to require stupid pointless actions from people people who know enough to run reliable file systems that don't need fsck on boot, is dumbing down the distro for the lowest common denominator -- when OSuse should be educating those users. Most users wouldn't need fsck if they new the reliability of xfs and it was the default root fs.
FWIW -- IRIX solved the problem before ram disks were common by providing something similar to an initrd/ramdisk that you'd copy to the swap partition and run from there -- a "miniroot", from which you could repair / modify root. That was in place 20 years ago. I never needed it. And in the past 12, I the one time I needed a root check, I could run it from a DVD (or now a USB key)...
Same problem similar but slower solution. IMHO a ramdisk is much faster as to misuse the swap paritition which may already contain the system image saved for Hibernate or Suspend-To-Disk.
Um... that was a solution they used 15-25 years ago with IRIX. I don't have an IRIX system -- no doubt it would be different today, but they used that 15 years ago, when multi-gig ramdisks were not possible. Today, I boot from a DVD. Which uses a ram disk to repair something that leaves the root file system inaccessible or destroys utils like 'mount' that live in /bin (at least on initrd...)..
It's not worth requiring something that only has to be done once every 12 years.
This is *your* personal opinion and you may consider that paying customers may have other essential requirements.
No it is not a personal opinion. It is an engineering opinion based on facts. The information you quoted to support your argument had nothing to do with "fsck".. XFS has no FSCK to run from initrd other than a shell script that tests if the disk is Mounted. For the root file system, that's a ridiculous thing to check for.
We're talking about less than 3 seconds used for initrd which could be safed by using the unsafe method you prefer.
Let's look at that safety and whether or not binaries must live in /usr/bin and /usr/sbin in order to boot... Looking at OSs's initrd, there is *nothing* in /usr/bin. In /bin, the initrd has: /tmp/initrd# ls bin awk@ chmod* date* ipconfig* ln* mkdir* mv* sed* sleep* uname* bash* chroot* dmesg* ipconfig.sh* logger@ mknod* rm* sh@ true* usleep* cat* cp* grep@ linuxrc* ls* mount* run-init* showconsole* umount* warpclock* --- In /usr/sbin: /tmp/initrd/usr/sbin# ll total 44 -rwxr-xr-x 1 38776 Jul 16 03:02 fsck* -rwxr-xr-x 1 450 Jul 16 03:44 fsck.xfs* /tmp/initrd/usr/sbin# more fsck fsck* fsck.xfs* -------------- (notice there is no call to anything that requires a file system be unmounted). ---and in /sbin Ishtar:tmp/initrd/sbin# ls biosdevname* blogd* fsck.xfs@ ifup* killall5* pidof@ resume* udevadm* blkid@ fsck@ halt* insmod* modprobe* reboot@ showconsole* udevd* ---- so Your initrd, DOESN'T have binaries in /usr -- but it boots just fine. If anything it is the libs in /usr/lib64: Ishtar:tmp/initrd# du lib64 7164 lib64 Ishtar:tmp/initrd# du usr/lib64 12620 usr/lib64 But compared to anything, moving that 12M from usr/lib64 to lib64... -- OSs's entire initrd could be on the hard disk and it would boot fine -- OSs' initrd doesn't need binaries in /usr and only uses a small number of libs in lib64 that could just as easily live in /lib64. So if the initrd OS's is using doesn't need any binary in /usr, why require it of customers? The major case one would need to boot from an initrd would be if they used a sub-optimal file system for root. That is a choice, but given a choice between something that will "just work", and something that needs checking -- for reliability, what would you choose? OSs' initrd is useless for checking a rootfs if the rootfs doesn't have an fsck! as is the case w/xfs). OSs' doesn't include any advanced disk check/repaire utils on the initrd -- so there can be no way to use the initrd to repair a root file system if it was corrupt. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org