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