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

[erich]

[Been pondering this issue for a while...]

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

> > On the other hand, the "remount" option doesn't seem to be a real
> > fix either.  Taking action with the remount option is not required
> > for all FSes, and it doesn't cause at least XFS to flush it's log.
> 
> Uggh... :(
> 
> > This makes me wonder how LILO solves the problem...  I'm going to
> > check to see if they even try to flush the log before checking the
> > block-map.  My guess is not, but it isn't a problem in general
> > because they're not copying files and then immediately checking the
> > filesystem structure for those files.
> 
> I don't think LILO requires filesystems to be flushed, because LILO
> uses raw devices only if it wants to read/write something from/to boot
> sectors, not within filesystems.

But it still has to get a block-map, even from a filesystem whose
journal isn't flushed.  It isn't necessarily guaranteed that any
filesystem will have decided where the blocks will finally reside
at the point of writing into the journal.

Though, I'm pretty sure ext3 and XFS at least have decided this by that
time, since they only journal metadata.  I'm not sure about JFS or
ReiserFS.


> As a solution, three ways can be considered:
> 
> 1. Wait for a while, hoping that your data is flushed to disks by
>    chance. This is quite easy and immediate.

But as we all have said, this is spooky/not really reliable.


> 2. Fix/Improve the implementations of Linux journaling
>    filesystems. This doesn't fix the problem unless you upgrade the
>    kernel.

Right, and frankly, I think people will ultimately end up resisting such
an implementation.  Fundamentally there is no reason to flush the
journal on a "sync" call since the filesystem is committed to stable
media and that's what the call is defined to do.

Other OSes behave this way as well, so GRUB wouldn't work there either.


> 3. Make a Linux-specific GRUB installer, instead of the grub shell,
>    like grubinst in the time of GRUB 0.4. This sounds too silly for
>    me, but this would solve that kind of problem in the more silly
>    kernel forever.

I would imagine it would be simplest to do this kind of thing as a
patch against the GRUB installer, probably with a Linux "#ifdef" in
it.

This may be the best thing.  Maybe I should just go figure this out
to ease my mind on what's going on with LILO and block-maps on the other
journaled FSes too.


I originally intended the GRUB "install" command to be run at boot-time
because that was really the only safe time/OS-independent way I could
see to do it.  The creation/use of the GRUB shell is clever, but not
guaranteed to be safe.


So, I'll try to have a patch soon, since I have a case that breaks the
existing one.


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