From: "David P. Quigley" <dpquigl@tycho.nsa.gov>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Valerie Aurora <vaurora@redhat.com>,
Erez Zadok <ezk-EX0cT3Az47bauI2f2gSDlQ@public.gmane.org>,
Trond Myklebust <Trond.Myklebust@netapp.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: Thu, 16 Jul 2009 17:22:28 -0400 [thread overview]
Message-ID: <1247779348.2516.136.camel@localhost> (raw)
In-Reply-To: <20090715172758.GA13893@fieldses.org>
On Wed, 2009-07-15 at 13:27 -0400, J. Bruce Fields wrote:
[snip]
> The mount options aren't really in the protocol--so it'd probably take
> the form of a filesystem-granularity attribute that the client could
> query (and then fail the mount if the client didn't like the answer).
>
> But even then: the fact is that someone will want to update the
> filesystem some day. And there's no way to force every client
> administrator to remount. So we'd have to decide how to handle that
> case.
So currently this is the case but at the last IETF meeting I proposed a
remount callback to handle the case of a mass file relabel on the
server. I think Beepy wrote it down on the possible 4.2 items. However I
wouldn't expect to see anything related to that for a while and that
assumes that someone picks up the ball and runs with it to begin with.
Dave
P.S. Note this is NFSv4 we are talking about I don't have a solution for
v2(does anyone even use it any more?) or v3
WARNING: multiple messages have this Message-ID (diff)
From: "David P. Quigley" <dpquigl-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
To: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
Cc: Valerie Aurora <vaurora-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Erez Zadok <ezk-EX0cT3Az47bauI2f2gSDlQ@public.gmane.org>,
Trond Myklebust
<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>,
Alexander Viro
<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Jan Blunck <jblunck-l3A5Bk7waGM@public.gmane.org>,
Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Union mounts, NFS, and locking
Date: Thu, 16 Jul 2009 17:22:28 -0400 [thread overview]
Message-ID: <1247779348.2516.136.camel@localhost> (raw)
In-Reply-To: <20090715172758.GA13893-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Wed, 2009-07-15 at 13:27 -0400, J. Bruce Fields wrote:
[snip]
> The mount options aren't really in the protocol--so it'd probably take
> the form of a filesystem-granularity attribute that the client could
> query (and then fail the mount if the client didn't like the answer).
>
> But even then: the fact is that someone will want to update the
> filesystem some day. And there's no way to force every client
> administrator to remount. So we'd have to decide how to handle that
> case.
So currently this is the case but at the last IETF meeting I proposed a
remount callback to handle the case of a mass file relabel on the
server. I think Beepy wrote it down on the possible 4.2 items. However I
wouldn't expect to see anything related to that for a while and that
assumes that someone picks up the ball and runs with it to begin with.
Dave
P.S. Note this is NFSv4 we are talking about I don't have a solution for
v2(does anyone even use it any more?) or v3
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-07-16 22:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-14 17:48 Union mounts, NFS, and locking Valerie Aurora
2009-07-14 17:48 ` Valerie Aurora
2009-07-14 18:19 ` Erez Zadok
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:19 ` Valerie Aurora
2009-07-14 20:36 ` Erez Zadok
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:05 ` Valerie Aurora
2009-07-14 22:33 ` Erez Zadok
2009-07-14 22:33 ` Erez Zadok
2009-07-14 22:55 ` Trond Myklebust
2009-07-14 22:55 ` Trond Myklebust
[not found] ` <1247612140.5332.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-07-16 0:15 ` Erez Zadok
2009-07-16 0:15 ` Erez Zadok
2009-07-15 0:19 ` Valerie Aurora
2009-07-15 17:27 ` J. Bruce Fields
2009-07-15 17:27 ` J. Bruce Fields
2009-07-16 17:25 ` Valerie Aurora
2009-07-16 17:25 ` Valerie Aurora
2009-07-16 21:22 ` David P. Quigley [this message]
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=1247779348.2516.136.camel@localhost \
--to=dpquigl@tycho.nsa.gov \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=ezk-EX0cT3Az47bauI2f2gSDlQ@public.gmane.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.