On Thu, Nov 15, 2012 at 01:10:29PM -0800, Linda Walsh wrote:
Dr. Werner Fink wrote:
Please be aware that most modern journaling file systems nowaday should be checked unmounted and with the internal system time of the kernel set to UTC (just in case if local time is used in CMOS) to have correct time stamps later on. That is such file systems may even not mounted ro before fsck has done its work. After the internal system time is in UTC and the file system (including its journal) is corrected by the file system check has been done the root file system can be mounted.
How do you want to do this without using an initrd? Please be aware that we would not do initrd stuff if not required to avoid data loose due corrupted file systems.
---- 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?
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): ... Regardless, the filesystem to be repaired must be unmounted, other- wise, the resulting filesystem may be inconsistent or corrupt. ... from xfs_check(8): ... The filesystem should normally be unmounted or read-only during the execution of xfs_check. Oth- erwise, spurious problems are reported. ...
To require to spend extra time and space for something that happens once in a Jovian year, is not logical. To use "modern" journaling file systems that haven't (almost though with ext4), but haven't quite gotten up to the level of an advanced corporate filesystem, doesn't quite make sense. With each revision ext4 gets closer... they've added features at each step that get it closer to xfs, but clearly they haven't hit the bar yet because, as you say, they require root-fsck's often enough to require it be offline and to boot from a ramdisk.
For any professional use it is a inalienable requirement to minimize the risk of data loose.
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.
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.
If you really want to use a file system that requires it more often, then having the option to boot from initrd is certainly something I have and still do, whole heartedly support, but to require it for all is certainly forcing the requirements of the lowest-common-denominators on everyone. It's effect is to try to eliminate any benefits from doing anything "different" -- when linux has always been about being able to configure the software to suite you. These types of changes make it EXTREMELY difficult to customize and optimize boot.
One of the reasons given for this whole mess was boot performance. But given the figures of going with no-initrd and xfs, that reason seems to have been dropped.
Is boot performance really a "we don't care, we're faster than 2-3-10 minute MS, so it doesn't matter?" OSse could be alot faster for EVERYONE if some basic conventions were observed, like the ability to have required HW modules statically linked and installed on your root -- and have your root FS be xfs. Then, no need for initrd.
We're talking about less than 3 seconds used for initrd which could be safed by using the unsafe method you prefer.
It could all be done automatically by scripts at run time -- (I wouldn't want it done at boot time if it were me -- when it is booting, I don't want to wait for a kernel compile that I can do myself in background when the system is running in a few minutes (2:22 w/>300 modules). All it takes is a willingness to want to do it rather than go the extremely round-about-way of loading a 20-40MB initrd (cf. my kernel=~5MB), which duplicates /usr/bin.
You asked how it could be done, I've mentioned more than one way -- it really depends on how often your rootfs needs to be checked. If it needs to be checked every boot...I would strongly advise most people to consider changing their rootfs.
Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org