All of lore.kernel.org
 help / color / mirror / Atom feed
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

           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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.