Re: Supported scenarios for bootloader installation (was: Re: [opensuse-factory] XFS Boot Problem)
Recently joined the list and read this thread in the archive, sorry I can't mend the threading. Comments on fsck(8) times on boot : The fsck time increase greatly with the size of the filesystem, especially once the data structures no longer fit into RAM, but end up using swap. A kernel modification to break a filesystem into chunks, for faster independant verification within the partition, was under development but I'm not sure if it made mainline use yet. By using a multiple file systems (and having generous RAM), I've not had issues with very slow fsck boot times, on my installations, but have seen the problem on servers installed by others. You could use init.d script, to mount certain large data file systems on boot (use noauto in fstab(5)), and also unmount with periodic fscks on shutdown to avoid long boot times. Windows systems suffer the same problem, only they tend not to have any integrity checks made without user intervention, and the first sign of trouble is boot failures or data corruption. For laptops, defining an adequate swap space and using the hibernate and resume features, makes more sense. Windows does have an advantage here, in that sleep, hibernate & resume are maturer, and have to be tested by Manufacturer pre-sale before a model is launched. Commentings on http://lists.opensuse.org/opensuse-factory/2008-12/msg00067.html Jiri Srain said : "The reason why reiserfs is not mentioned is its complexity; for booting, you should prefer a filesystem which is as simple as possible to avoid problems which Josef posted in regard of XFS. Even though I'm not aware of any single case when reiserfs didn't work for booting, our goal was to define scenarios which we believe that will keep working in the future. I still remember that when reiserfs was introduced, the only way to use it for booting was to disable sharing of a sector by tails of multiple files (notail option). " Some comments on the reasons for recommended practice, on /boot partions, remembering those times to. SuSE introduced this fast jornalled filesystem into 2.2 (either a late 6.X release of 7.0); and reiserfs was the only journalled filesystem to make into the mainline 2.4.0 kernel (somewhat controversially at last minute, but thanks Linus!). GRUB got introduced a bit later, I think in SuSE-8.X. reiserfs and the VM, were far more stable under SuSE, than other popular distro's, because some patches weren't included in mainline, with RedHat's kernel team for instance committed to subsystems developed and maintained by their inhouse teams. ext2 was recommended for /boot because it lacked a journal file. /boot as a seperate partition was made small, perhaps only 32-64MiB, so a journal taking 1/3-1/2 space was rather wasteful. A small seperate /boot was fast to fsck(8) and load, and avoided any BIOS issues with cylinders falling above 1024. BIOSes were very, very flakey and generally only tested with DOS/WIN9X. reiserfs being fairly new, wasn't recognised by some common rescue disks. "notails" to avoid files packed into blocks, was due to LILO working with LBA blocks, not the filesystem. reiserfs disk layout and code, was not nearly so stable. Future updates might occur and break GRUB, until it's code was updated. GRUB did understand the filesystems, but some like (ext2) were better tested than others. It is perfectly possible to mount /boot ro, or have it as noauto during normal use, to avoid fscks and accidents like deleting (overwriting) the running kernel. Unfortunately the kernel update mechanism, did not fail gracefully if /boot unmounted, and bug reports seemed to be ignored. So until there's more sanity checking for the kernel update (not sure if it's a YaST2 or kernel rpm issue) it's better to mount /boot conventionally. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob OpenSuSE napsal(a):
Recently joined the list and read this thread in the archive, sorry I can't mend the threading.
Comments on fsck(8) times on boot :
The fsck time increase greatly with the size of the filesystem, especially once the data structures no longer fit into RAM, but end up using swap. A kernel modification to break a filesystem into chunks, for faster independant verification within the partition, was under development but I'm not sure if it made mainline use yet. By using a multiple file systems (and having generous RAM), I've not had issues with very slow fsck boot times, on my installations, but have seen the problem on servers installed by others.
You could use init.d script, to mount certain large data file systems on boot (use noauto in fstab(5)), and also unmount with periodic fscks on shutdown to avoid long boot times.
Windows systems suffer the same problem, only they tend not to have any integrity checks made without user intervention, and the first sign of trouble is boot failures or data corruption.
For laptops, defining an adequate swap space and using the hibernate and resume features, makes more sense. Windows does have an advantage here, in that sleep, hibernate & resume are maturer, and have to be tested by Manufacturer pre-sale before a model is launched.
Commentings on http://lists.opensuse.org/opensuse-factory/2008-12/msg00067.html
Jiri Srain said : "The reason why reiserfs is not mentioned is its complexity; for booting, you should prefer a filesystem which is as simple as possible to avoid problems which Josef posted in regard of XFS. Even though I'm not aware of any single case when reiserfs didn't work for booting, our goal was to define scenarios which we believe that will keep working in the future.
I still remember that when reiserfs was introduced, the only way to use it for booting was to disable sharing of a sector by tails of multiple files (notail option). "
Some comments on the reasons for recommended practice, on /boot partions, remembering those times to.
SuSE introduced this fast jornalled filesystem into 2.2 (either a late 6.X release of 7.0); and reiserfs was the only journalled filesystem to make into the mainline 2.4.0 kernel (somewhat controversially at last minute, but thanks Linus!). GRUB got introduced a bit later, I think in SuSE-8.X. reiserfs and the VM, were far more stable under SuSE, than other popular distro's, because some patches weren't included in mainline, with RedHat's kernel team for instance committed to subsystems developed and maintained by their inhouse teams.
ext2 was recommended for /boot because it lacked a journal file.
/boot as a seperate partition was made small, perhaps only 32-64MiB, so a journal taking 1/3-1/2 space was rather wasteful. A small seperate /boot was fast to fsck(8) and load, and avoided any BIOS issues with cylinders falling above 1024. BIOSes were very, very flakey and generally only tested with DOS/WIN9X.
reiserfs being fairly new, wasn't recognised by some common rescue disks.
"notails" to avoid files packed into blocks, was due to LILO working with LBA blocks, not the filesystem.
reiserfs disk layout and code, was not nearly so stable. Future updates might occur and break GRUB, until it's code was updated.
GRUB did understand the filesystems, but some like (ext2) were better tested than others.
It is perfectly possible to mount /boot ro, or have it as noauto during normal use, to avoid fscks and accidents like deleting (overwriting) the running kernel.
Unfortunately the kernel update mechanism, did not fail gracefully if /boot unmounted, and bug reports seemed to be ignored. So until there's more sanity checking for the kernel update (not sure if it's a YaST2 or kernel rpm issue) it's better to mount /boot conventionally.
I disagree with last paragraph. To 11.1 I added check for unmounted boot, which says quite verbose, that /boot is not mounted. In some case with chroot it have problems, but you can skip this check with enviroment variable. If you interested, I can post some bugs related to that. JR -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2008/12/17 josef reidinger
Rob OpenSuSE napsal(a):
Unfortunately the kernel update mechanism, did not fail gracefully if /boot unmounted, and bug reports seemed to be ignored. So until there's more sanity checking for the kernel update (not sure if it's a YaST2 or kernel rpm issue) it's better to mount /boot conventionally.
I disagree with last paragraph. To 11.1 I added check for unmounted boot, which says quite verbose, that /boot is not mounted. In some case with chroot it have problems, but you can skip this check with enviroment variable. If you interested, I can post some bugs related to that.
That's great news! After I've grabbed 11.1 GM, I'll test and find my old bug report filed to 10.3 and make sure it has been marked as resolved. Josef, I do hope you noticed the "element of doubt" and also the past tense (historical comment). I was bitten very badly by a kernel update during 10.3, so part of the reason to comment was in hope of an update as interest in "small is beautiful" /boot filesystems had been shown; no offense was intended. This change will help system reliability and make disaster recovery easier, thank you! What I'd shall actually start doing on test boxes, is a shared /boot_consolidated filesystem, to support different distro's and releases, without using an unmanageable number of partitions ie. 1 small boot partition for temporary use by the installer, plus the consolidated boot fs, with /boot bind mounted into the right place in the consolidated filesystem tree. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2008-12-17 at 12:40 -0000, Rob OpenSuSE wrote: ...
Unfortunately the kernel update mechanism, did not fail gracefully if /boot unmounted, and bug reports seemed to be ignored. So until there's more sanity checking for the kernel update (not sure if it's a YaST2 or kernel rpm issue) it's better to mount /boot conventionally.
This is checked for now. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklJB6UACgkQtTMYHG2NR9VM8QCglQBXiv7x4ljvB0l1m3O8xUD5 wtEAoIft/OLBqaGvyX/TWpNwSgo/tXII =dpw1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (3)
-
Carlos E. R. -
josef reidinger -
Rob OpenSuSE