Bug#239111: Grub is shockingly bad code

[Robert McQueen]

Robert Millan wrote:
> It would seem that running sync would suffice for that.  Unfortunately, it
> seems that:
> 
>   - sync is not enough
>     (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#53)

Correct. This is a property of XFS. As I said, it considers that putting
metadata into the journal, and knowing it's flushed there, to meet the
API guarantee of sync(). sync() doesn't make any guarantee that the
files can be found by an an incomplete implementation of the filesystem
(such as GRUB's, which ignores the journal).

>   - xfs_freeze could hang even if you don't write anything
>     (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#194)

I believe this report is unreliable, perhaps it froze because it's made
an echo in a process whose stdout is being logged?

> This is odd.  I think I'm going to assume sync does what is expected from
> it.  If it doesn't maybe it's a bug in Linux, which maybe got fixed already,
> or maybe it's a (lesser) bug in GRUB which we can't find untill it's
> exposed.

It's not a bug, it's the behaviour of XFS which I've explained a few
times already. The bug in GRUB is trying to read the filesystem at a
block level, behind the kernel's back.

> In any case, we're better off not using xfs_freeze untill we know for sure
> why it is needed, and are certain it won't cause hangs.

I know why it's needed, and have done for around 4 years, and have had
this confirmed from the XFS developers too.

> I'm waiting for Ron's confirmation that this works for him, and then I'll
> remove the patch & upload.

I'm pretty sure it won't work reliably without some xfs_freeze, so I
still prefer including the patch. I will try to find some time to test
it as well as Ben's simple freeze; unfreeze patch which I prefer, as I
believe it will make things work in lenny's kernel (although not etch,
where freeze is sadly broken, which is why the patch in #179 has such
horrible looping sleep/freeze hacks anyway).

Cheers,
Rob