Re: Union mounts, NFS, and locking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In message <1247612140.5332.11.camel@xxxxxxxxxxxxxxxxxxxxx>, Trond Myklebust writes:
> On Tue, 2009-07-14 at 18:33 -0400, Erez Zadok wrote:
> > How would the client detect that the server broke the promise?  In theory,
> > your client may never know b/c it'll never send the server any
> > state-changing ops (e.g., creat, write, unlink).  One really ugly idea might
> > be for the client to try and create a dummy .nfsXXXXXX file on the server,
> > and if that succeds, or the error returned isn't EROFS, the client can guess
> > that the server's misbhaving.
> 
> That still doesn't guarantee anything:
> 
> cat /etc/exports
> /export	10.0.0.0/24(ro,sync) 10.0.1.1(rw,sync)
> /export/home 10.0.0.0/24(sec=krb5i:krb5p,rw,sec=sys:krb5,ro)

Agreed.  One more example why trying to enforce read-only-ness (or any other
term Bruce prefers :-) is going to be too hard to do at this stage.  I think
we can live with a client-side "promise" via a mount option for now.

> Both of the above are liable to return EROFS to some clients, but not
> others...
> 
> NFSv4.1 directory delegations can do the job of notifying you if the
> directory contents change, but what should your unionfs do when it gets
> told that this is the case?

Good to know about these delegations in 4.1.  They could be useful for any
stackable layer including union mounts and even ecryptfs, to handle cache
coherency across the layers more gracefully.  At the very least it could be
used to purge stale caches.  Even w/ union mounts, some operations could be
expensive: e.g., directory name merging and duplicate elimination; hence
it's likely the result of such a merge would be cached somewhere.  This
cache can get stale if a directory that's part of the name merge has changed
on the server.  So a unioning solution might want to know this.

(Directory delegations may also be more efficient than the traditional
NFSv2/3 way to validating the attrcache; IIRC, the client has to check that
the parent dir mtime hasn't changed before using a cached attribute.)

BTW, will nfs4.1's directory delegations be able to inform about namespace
changes only, or would they also be able to inform the client about file
data which had changed.

> Cheers
>   Trond
> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@xxxxxxxxxx
> www.netapp.com

Thanks,
Erez.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux