Rob OpenSuSE wrote:
On 2 July 2011 02:41, Linda Walsh
wrote: Adam Tauno Williams wrote:
XFS works well, I've never noticed it not supported.
SIMPLE RULE: Create a 256MB ext3 /boot partition. �I do this on every box running any distro - and as I said - I've never had a boot issue. Then put everything else in LVM on whatever filesystem you like. Um...
� � � �your idea of 'advanced' and mine aren't the same. � My advanced includes specifying the mount params on my xfs partitions �-- INCLUDING the root partition.
� � � �If I used your setup, I'm pretty sure my system would not boot, since I'm pretty sure, IF I built in ext3 support in my kernel, at best, it would be a module, located on the XFS boot partition.
The modules in the initrd which is loaded into memory via BIOS calls
Full stop. I said: I'm booting from my Hard Disk -- Not from a RAM DISK. There is no 'initRD'. Thus there are no drivers available to the kernel until it mounts the disk. Maybe it was in a different thread, but I had problems getting my own kernel to boot properly from the suse initRD. For some reason I couldn't get any console output during boot until I hit the login prompt. I had the same verbosity flags set on that image as on the standard suse images...so, given the suse ramdisk seemed to have problems booting a virgin-source kernel (i.e. no suse applied patches) and after several attepts, I went to lilo which didn't require a ram disk and didn't disable output during boot.
There was a post on this list few years ago, explaining the problems for the YaST Perl Bootloader, GRUB and XFS, which meant it was unsupported due to it's YMMV nature in the general. lilo may have worked as it uses block lists, rather than read the filesystem format, but that fails on system like BTRFS with auto-defragmentation planned.
The reason GRUB and XFS didn't get along at that time was that GRUB went out and read to read file meta data information on an actively mounted file system. No matter how many times you type 'sync', you can have race conditions -- AND a journaling file system only adds to those potential problems. However, as I understand it, Grub was fixed some time ago. XFS defragments files as well -- not be default, though my system is setup to automatically defragment my file systems each night. However, there is also a "do-not-defragment" bit that can be set on files or directories. If set on a directory, the "do-not-defrag" status is inherited by any subsequent files or directories created in that directory. Thus setting the 'do-not-defrag' bit on /boot, prevents problems with lilo. One would hope that BTRFS wouldn't be so primitive as to give the user no control over such operations (for reasons as you describe).
GRUB can however use (for reliability possibly only as fallback) copies of the distro "/boot" files, from a partition that's usually not mounted. It just means self updating of Menu file and adding new kernel files to the /real/GRUB/boot partition. Then there's little need for "advanced" file sytems with journalling, and you get around the restrictions on new filesystems like BTRFS.
But the whole point, in my case, was to only need 1 filesystem driver built into my kernel (sometimes I do have modules built if I am testing or benching a new file system), but those are generally not loaded unless I'm actually using one of those file systems. My current kernel has BTRFS, NILFS, UserFS, MSDOS_FS, all set as modules. of those only UserFS is currently loaded. XFS is the only FS built into my kernel. You were making assumptions about my setup that are not true. Sorry for the confusion. Linda -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org