From: Nathan Scott <nscott@aconex.com>
To: xfs-masters@oss.sgi.com
Cc: xfs@oss.sgi.com
Subject: Re: [xfs-masters] XFS and booting
Date: Fri, 16 Mar 2007 17:01:48 +1100 [thread overview]
Message-ID: <1174024908.5051.230.camel@edge> (raw)
In-Reply-To: <45FA1605.6080405@zytor.com>
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
parent reply other threads:[~2007-03-16 6:02 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <45FA1605.6080405@zytor.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1174024908.5051.230.camel@edge \
--to=nscott@aconex.com \
--cc=xfs-masters@oss.sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox