I have been seeing the same problem in very specific cases of
using software RAID 1 and accessing a Samba share with smbclient.
I never see it any other time and not every time in this
configuration. In addition, it seems to help reproduce this
if the RAID 1 is resyncing and smbclient is doing more than
16 clients in a 64 MB configuration on the server. Therefore,
it is doing some swap.
I applied Andy's patch and am trying to reproduce again.
From: utz lehmann
To: Steve Lord
Sent: 2/13/01 5:52 PM
Subject: Re: less data lost, more fs corruption
Steve Lord [lord@xxxxxxx] wrote:
> > the first 6-8 test succeeded.
> > i cycled the tests without clean shutdowns between (hmmm maybe one
> > then i made only one sync. after reboot some files differ. same
> > size is ok, but no extents. the number of differs are small.
> Have you tried this with ext2?
no. shoud i?
> OK the real issue here is that sync is not really doing sync, the sync
> call is starting I/O, but not waiting for it to complete. At least two
> are probably necessary for this scenario right now. If you wait a few
> there will be a kernel initiated sync anyway. And as Ananth pointed
> there are some bits of I/O which will take a couple of passes to get
> Obviously we cannot immediately flush everything to disk or
> would tank. The issue with XFS in this area has always been that the
> inode size gets out to disk in advance of the file data. You are
> at a consistent filesystem, it just has data missing! This is why
> does not complain.
ok, when the return of sync means "writing data to disk will done"
"writing data to disk is done" then the fix works.
btw: with 3 syncs and reset in less than a second lost data is seen.
is this on irix the same? sometimes i found those no extend files on
after a crash.