On Mon, 2009-11-09 at 17:13 +0200, Ivan Yosifov wrote: > On Mon, 2009-11-09 at 08:25 -0500, Trond Myklebust wrote: > > On Mon, 2009-11-09 at 14:42 +0200, Ivan Yosifov wrote: > > > Hi everyone, > > > > > > I'm new to NFS and am trying to understand how to use it safely and > > > correctly. > > > > > > The situation I'm considering is following. There's a server with an > > > ( ext4 if it matters ) local volume that's exported through NFSv4. There > > > are expected to be both remote ( ie. over the NFS ) read/write clients > > > and local ones that write to the volume directly ( ie. not thorough the > > > NFS ). > > > > > > Assuming well-behaved clients, ie. no interleaved open()...close() on > > > the same file, how will NFS handle this ? Will close-to-open consistency > > > continue to work, will it interfere with delegations ? > > > > > > Pointers or thoughts greatly appreciated. > > > > The NFS expectation is that if one application is writing to a file > > while another is holding it open, then the two applications will use > > locking in order to synchronise their access. > > So I understood. So far so good. > > > As long as all applications adhere to this rule, then you are supposed > > to be guaranteed cache consistency. It shouldn't matter if the > > applications are running on the server or on another client. > > > Cheers > > Trond > > > > Sounds encouraging. Just to clarify, I assume local writers don't pass > through NFS. > > Out of curiosity, do you know how it's implemented ? > > I looked at fs/nfsd and fs/nfs in the kernel source but didn't really > understand a lot. I got the impression that nfs clients and the server > pass nfsd4_change_info objects ( defined in include/linux/nfsd/xdr4.h ) > around with the before_change and after_change fields being "file > version" of sorts - ie. they are changed when the file is changed and > don't depend on timestamp resolution or anything like that. > > My concern is that the normal fs has only timestamps ( right ? ) which > have a finite resolution and can't be used as file version indicators. > So it seems necessary for the normal fs code to notify the NFS code for > every write/change to a file that's also opened through NFS. Such a Ugh, sorry, I mean was opened through NFS, then closed and the latest change info is still cached. Then it is invalidated by the direct local write. The invalidation must somehow be signaled to the NFS server, it seems. > tight coupling both seems hard to get and I didn't notice anything like > it in the source. > > Thanks, > Ivan > > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
