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

[erich]

Thierry Laronde <address@hidden> wrote:

...
> > Are you talking about tests with the loopback device?  Or do you know
> > this problem is endemic with all device types.
> > 
> > The loopback device in Linux has some shortcuts in it (at least it did
> > as of some time ago when I looked at it), so I could believe that "sync"
> > didn't work quite correctly with it.
> 
> Since the aim was to create virtual disks, indeed, I only used the
> loop device in Linux. But since you encountered the very same kind
> of behavior, I made the assumption that the problem was at a more
> "general" level in Linux, the way fs is handled via some cache strategy.
> 
> So, yes, for me : only on loop device [others untested].


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.

Linux normal "sync" behavior looks fine for real devices.  (for
non-journaled FSes)


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.

The closest thing there was remounting as read-only, which both
XFS and ReiserFS then appear to flush their logs to put it in a
nice consistent read-only state.  This would tend to hose a running
system, though.


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.

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.


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