Re: Worse yet Re: Whoops! Re: [PATCH] Another semi-critical one... (was Re: towards 0.91 )

[erich]

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

> If my understanding is correct, ReiserFS only journals metadata,
> too. I don't know much about JFS.

JFS is metadata-only.


> However, if all the journaling filesystems don't journal the contents
> of files, as Jochen pointed out, wouldn't it be enough for us to
> add support for reading journals of XFS and JFS into GRUB? I see no
> reason why we need to flush journals, once GRUB has real support for
> journaling filesystems, like ReiserFS.

Turns out this is not quite the case.  Several have pointed out to me
that ext3 has a different mode which journals data as well (and after
sniffing around, it seems that you can even change the semantics of
write ordering as a "journaling mode", ack!!!  but that's not relevant
here...).

Personally, I am *very* wary of reading the journal on a filesystem
mounted for writing, because by definition it changes very fast.  You'd
be getting inconsistency errors all over the place when the journal
has something in it that isn't in the main filesystem on-disk structures
yet.


>  ... However, I want to say, it should be possible to make the
> GRUB installation on a running system as robust and reliable as that
> on a bare system, in most situations. We should always warn the
> danger, but I don't want to stop improving it.
> 
> BTW, I think the REISERFS_IOC_UNPACK ioctl would be a Good Thing to
> have, as GRUB requires to be aligned. Any volunteer?

I Used The Source looking over the FIBMAP functionality in Linux
that LILO uses, and am in the process of generating a patch for the
grub shell.  It should be easy to add in the above ioctl in the
process, though I won't be able to test it well since I have no system
with ReiserFS as the root partition (I have ext3 and XFS systems).


But on the front of making the GRUB shell-based installer "grub-install"
run more reliably on random systems, I had an idea which I think should
be used even with the non-journaled filesystems.

As is, there are GRUB shell-specific features like the "--stage2" option
in the "setup" command.

#1:  I think we add a "--mapdump" feature that spits out a simple
file listing all the blockmaps.  Then we run the final stage of
the GRUB shell in "grub-install" something like 3 times with short
delays and compare the results to see if they are all identical (you
don't even need a terribly nice format, just something you can run a
binary compare on).  If not, then a simple retry mechanism after a
delay, and if a few delays don't cause it to settle down, you give up.

This also has the benefit of ensuring even non-journaled FSes are in
a stable state.

#2:  Add at least some support for journals, so that you can at least
recognize when it's not empty and maybe just error out in a way that
"grub-install" can then print out "journal not flushed, delaying...",
puts in a wait, then tries again.  Obviously any such behavior where
it errors out would only be in the GRUB shell, not the bootloader
version.


What do you think?


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