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

[Thierry Laronde]

On Sat, Oct 27, 2001 at 02:30:32PM -0700, address@hidden wrote:
> 
> address@hidden wrote:
> 
> > OK, I feel a bit sheepish...
> > 
> > "sync" is already being called from the grub shell, which only makes
> > sense...  so in general the fix I posted should have been a no-op.  It's
> > not a bug per se, just unnecessary.
> > 
> > But on RedHat 7.2 with the kernel update to 2.4.9-7, something is
> > busted to make me have to call it explicitly in the shell script.
> > 
> > Effectively, the "sync" call was made several times with some small
> > delays in-between.
> 
> I just realized what the real bug is, and it's a problem for the
> GRUB shell in general, and "grub-install" especially.
> 
> The "sync" system call, as a performance enhancement, almost certainly
> returns when the journal for the metadata is finished being written
> rather than waiting for the journal to be emptied to the final on-disk
> structures like GRUB expects.

For what is worth, when I wrote `mkbimage' (script to create bootable
virtual disks with GRUB --- http://corpus.polynum.org/admin/mkbimage) I
first tried to `sync' because there were errors about stage1 and stage2
(not found by the GRUB shell on the loop device) and this didn't work. I
finally umount the loop after detarring the files, and remount before
calling the GRUB shell and everything works correctly now. So :

- it's not journalized fs dependant (I have no)
- it's not Redhat dependant (I'm under Debian)
- it's perhaps a problem with the way the GRUB shell handles the
  devices, but it's clearly a cache problem, and it might be a kernel
  one.

  Cheers,
-- 
Thierry Laronde (Alceste) <address@hidden>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C