Re: More fun with fsx.

Trond Myklebust (trond.myklebust@fys.uio.no)
Sun, 16 Dec 2001 19:48:45 +0100


>>>>> " " == Dave Jones <davej@suse.de> writes:

> On Sun, 16 Dec 2001, Dave Jones wrote:
>> > > Full log of the failcase is at
>> > > http://www.codemonkey.org.uk/cruft/nfs-fsx.txt
>> > Which kernel and mount options?
>> client 2.4.13-ac5, server 2.4.17rc1, default options, nothing
>> special. I'll try to reproduce with a newer kernel on the
>> client.

> Yup, it's still there with 2.4.17-rc1 as the client too. Exact
> same failure.

I found the bug. It's a pretty ugly race...

The problem is that although the inode->i_sem semaphore protects you
against races with ordinary writes, it does *not* protect you against
the memory management routines (such as page_launder()) from calling
writepage() on dirty pages.
For most local filesystems, this is not a problem, since they can call
vmtruncate() *before* they do their thing on the disk itself. For
non-local filesystems, you usually can't do this, since you cannot
guarantee that the RPC call will succeed on the server.

The only solution I can see, is to force a synchronous write of those
dirty pages to the server prior to calling setattr. I've updated the
patch on

http://www.fys.uio.no/~trondmy/src/2.4.17/linux-2.4.17-fattr.dif

to do this. Fixes the race for me...

Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/