Hi,
On Thu, 2007-03-15 at 20:59 -0700, H. Peter Anvin wrote:
> I have been looking at adding XFS support to the syslinux bootloader
> suite, and discovered, to my dismay:
>
> No, for root partition installations because the XFS superblock is
> written at block zero, where LILO would be installed. This is to
> maintain compatibility with the IRIX on-disk format, and will not be
> changed.
This FAQ entry could probably be worded a bit more diplomatically.
It is both the IRIX format (11+ years) and the last 6+ years of use
of XFS on Linux by many, many people (and many SGI / other companies
paying customers) that prevents this kind of change at this stage.
> This means that it's impossible to write a boot loader that actually
> plays by the x86 platform rules and still can boot from XFS. Other than
Using lilo with an xfs root via the boot=/dev/hda and root=/dev/hda1
method (i.e. non-root-partition MBR) has been working OK for me and
others. Is that not playing by the rules? Is that an option for
your setup? It's a third option to the two you listed anyway (grub
vs /boot, I mean).
> the GRUB option of spreading itself all over the disk in places it
> shouldn't be, like the MBR, thus breaking e.g. softraid and creating all
> kinds of unnecessary interoperability problems.
>
> Anyway, since it looks like the damage of not offsetting the filesystem
> has already been done, I'm trying to figure out what, if anything, can
Or, worded another way, "the damage of designing a system having an MBR
in the first sector of space that is then allocated to filesystems" -
it's a shocker of a layering violation.
> be done about it. A standard MBR will never be able to boot an XFS, but
> perhaps a slightly modified MBR can be made to do that, without
> introducing filesystem-instance-specific issues. In particular, if
> there is space anywhere in the superblock for a "boot sector pointer",
> *and* there is a way to safely write this pointer, then a slightly
> modified MBR could detect an XFS superblock and re-read a boot sector at
> that offset.
>
> Is this something that could be done?
It could be done - thats not the sound of me volunteering though ;) -
there is space available in most XFS filesystem geometries that could
be reclaimed for this kind of thing.
For example, for a 512 byte sector filesystem with a 4K blocksize, we
have unused sectors at bytes 2048->4096 (following the space used for
the first 4 sectors - SB, AGI AGF, AGFL, but before the first fsblock).
This is the default mkfs geometry, so by far most filesystems have the
free space here that could be utilised by a boot loader. And there's
plenty of space in the superblock for a field with the meaning "the
boot sector lives here". Actually, it'd be pretty straightforward to
do this in XFS - the trickier part is working out in mkfs all of the
geometries which do not result in freespace available for a boot sector,
but thats not really very hard either.
The important question is, would anyone use it, if such a feature was
available? Eric/I/... well, anyone could probably hack up the XFS code
in a weekend to allow someone to test this out, but I'd want to be very
sure it wasn't going to be wasted effort...
cheers.
--
Nathan
|