From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Erez Zadok <ezk@cs.sunysb.edu>
Cc: Valerie Aurora <vaurora@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jan Blunck <jblunck@suse.de>,
Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: Union mounts, NFS, and locking
Date: Tue, 14 Jul 2009 18:55:40 -0400 [thread overview]
Message-ID: <1247612140.5332.11.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <200907142233.n6EMXRQp019008@agora.fsl.cs.sunysb.edu>
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)
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?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
next prev parent reply other threads:[~2009-07-14 22:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-14 17:48 Union mounts, NFS, and locking Valerie Aurora
2009-07-14 18:19 ` Erez Zadok
[not found] ` <200907141819.n6EIJQi1014319-zop+azHP2WsZjdeEBZXbMidm6ipF23ct@public.gmane.org>
2009-07-14 20:19 ` Valerie Aurora
2009-07-14 20:36 ` Erez Zadok
[not found] ` <200907142036.n6EKaexe017464-zop+azHP2WsZjdeEBZXbMidm6ipF23ct@public.gmane.org>
2009-07-14 22:05 ` Valerie Aurora
2009-07-14 22:33 ` Erez Zadok
2009-07-14 22:55 ` Trond Myklebust [this message]
[not found] ` <1247612140.5332.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-07-16 0:15 ` Erez Zadok
2009-07-15 0:19 ` Valerie Aurora
2009-07-15 17:27 ` J. Bruce Fields
2009-07-16 17:25 ` Valerie Aurora
2009-07-16 21:22 ` David P. Quigley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1247612140.5332.11.camel@heimdal.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=ezk@cs.sunysb.edu \
--cc=hch@infradead.org \
--cc=jblunck@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=vaurora@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox