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: Jochen Hoenicke
Subject: Re: Worse yet Re: Whoops! Re: [PATCH] Another semi-critical one... (was Re: towards 0.91 )
Date: Thu, 1 Nov 2001 11:31:13 +0100

On Oct 31, address@hidden wrote:
> Linux normal "sync" behavior looks fine for real devices.  (for
> non-journaled FSes)

I just want to point out, that for a journaled filesystem, once the
journal blocks are committed from a logical point the filesystem is
completely synced.  There is no need for the driver to flush the
blocks to their real location immediately.

The grub reiserfs driver knows about the journal and honours it (it
remaps read accesses to the blocks in the journal log if they are
present there).  You shouldn't see any problems with reiserfs.  IMHO
XFS and JFS should also honour the journal.  Note that grub otherwise
could have problems booting from a half flushed disk, e.g. after a
power failure.

There is still a problem with the linux "sync" behaviour and it's
partition handling.  Linux has its own buffer cache for each block
device, e.g one cache for /dev/hda and one for /dev/hda1.  If you read
a block from /dev/hda it is placed in its buffer cache.  Then you can
write something to the same block over /dev/hda1 flush it to disk, but
the buffer cache of /dev/hda doesn't notice that and still reads the
old data.  There is no call to invalidate that cached data.  As grub
accesses the disk through /dev/hda while linux fs driver access it
through the partition /dev/hda1 they can be out of sync despite
calling sync everywhere.

  Jochen



reply via email to

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