Messages in this thread |  | | | Date | Sun, 16 Dec 2001 19:48:45 +0100 | | Subject | Re: More fun with fsx. | | From | Trond Myklebust <> |
| |
>>>>> " " == 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/
|  |