bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Yoshinori K. Okuji
Subject: Re: Worse yet Re: Whoops! Re: [PATCH] Another semi-critical one... (was Re: towards 0.91 )
Date: Thu, 01 Nov 2001 11:52:26 +0900
User-agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryomae) APEL/10.3 Emacs/20.7 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN)

At Wed, 31 Oct 2001 17:45:00 -0800,
address@hidden wrote:
> My check of the code was not thurough, but the loop device seems to
> be the culprit, when the "device" is actually a file.  There is
> no apparent linkage with the way a "sync" is done, so it looks like
> a timing problem with the fact that after writing out the blocks, it
> would then have to sync that other filesystem again.  There is no
> transitive closure for stacked devices in Linux right now.

That's likely to be. Perhaps the reason why I didn't notice that Linux
didn't do sync well when I used loop devices is that when using a file
as a drive in GRUB, it is unnecessary to mount it via a loop
device, since GRUB has the command "device", which is more powerful
than Linux's loop devices in a sense.

> 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.

> The sticky point here is that the "grub-install" script unconditionally
> insists on copying those files, which puts the metadata for those files
> in flight.  A (arguably kind of silly) helpful point might be to do a
> "cmp" of the source and destination files beforehand and not copy them
> if they're the same.

This might help you, but I don't think this could be a Saviour for
most people, because ordinary users install boot loaders only when
they install OSes from scratch.

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.
2. Fix/Improve the implementations of Linux journaling
   filesystems. This doesn't fix the problem unless you upgrade the
   kernel.
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.

Okuji



reply via email to

[Prev in Thread] Current Thread [Next in Thread]