GRUB shell consistency with Filesystem

[erich]

[Thought I'd give this thread a better subject line]


"Yoshinori K. Okuji" <address@hidden> wrote:

...
> BTW, I think the REISERFS_IOC_UNPACK ioctl would be a Good Thing to
> have, as GRUB requires to be aligned. Any volunteer?

I looked at this call a bit, and it strikes me that supporting this
is the Wrong Thing for 2 reasons:

  1) Having filesystem-specific hacks is kind of a mess.  Keeping the
     code generic makes it MUCH more likely to work correctly and be
     maintainable.

  2) The right way to fix this is to generalize the blockmap feature
     to make it support partial blocks.  Other filesystems will likely
     do this in the future, so it's better that we just bite the bullet.

Any comments on #2?


In fact, I think both LILO and ReserFS (and arguably Linux in general)
have gone the wrong way with their blockmap/unpack code/ioctls.

The Right Way to do this would be to make a program called "mkbootloader"
or something that will take a filename and do 2 things with it:  produce
a blockmap in a well-known format, and communicate via a generic ioctl
(NOT a filesystem-specific one) that it needs to be on hardware block
boundaries and be in a fixed location.

GRUB should use then this program and take the blocklist as input to set
up it's installer.

The issue here is that there will be steadily more and more exotic
filesystems out there, perhaps some that will migrate/re-de-fragment
disks on the fly, who knows?  So, there has to be a way to communicate
to the filesystem that some file may be read outside of the context
of the normal running system, and to leave it marked that way.

In the meantime I've done a few experiments on the current GRUB shell
to improve it's consistency with the disk, will post a follow-up on
the results shortly.


Related to this, I think we should remove the "--stage2" feature from
the GRUB shell.  Some filesystems (none that GRUB supports currently,
but ReiserFS is considering it for v4) can allocate new blocks upon
writes, so using the filesystem code to write to the disk could
invalidate the blockmap made of the stage2.


--
    Erich Stefan Boleyn     <address@hidden>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"