linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Malahal Naineni <malahal@us.ibm.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: State of NFSv4 VolatileFilehandles
Date: Wed, 03 Aug 2011 22:12:39 -0400	[thread overview]
Message-ID: <1312423959.2304.10.camel@lade.trondhjem.org> (raw)
In-Reply-To: <20110804011611.GA24568@us.ibm.com>

On Wed, 2011-08-03 at 18:16 -0700, Malahal Naineni wrote: 
> NeilBrown [neilb@suse.de] wrote:
> > 
> > I substantially agree, though I think the implication can be refined a
> > little.
> > 
> > I would say that the implication is that a VFH is only really usable
> > when the complete path leading to the file in question is read-only.
> > We don't need to assume that other files in other parts of the
> > hierarchy which have stable file handles are read-only.
> > 
> > So if the server presents us with a VFH, it seems reasonable to assume
> > that we can use a repeated lookup of the same name to refresh the
> > filehandle simply because there is no other credible way to respond to
> > a FHEXPIRED.
> 
> The spec seems to imply that repeated lookup of the same name to refresh
> the file handle is OK as long as the file is OPEN! It doesn't seem to imply
> anything for files that are not opened.

I see no such implication for a migration situation, unless you also
migrate the open state.

Even if you do, then you still have to somehow recover directory
filehandles for the current directory and any other RPC call that
happened to be in progress when the original server was migrated.

> "RFC 3530, 4.2.3. Volatile Filehandle" states:
> 
> "Servers which provide volatile filehandles that may expire while open
> (i.e., if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if
> FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should deny
> a RENAME or REMOVE that would affect an OPEN file of any of the
> components leading to the OPEN file.  In addition, the server should
> deny all RENAME or REMOVE requests during the grace period upon server
> restart."
> 
> On the other hand, if FH4_NOEXPIRE_WITH_OPEN is set, then the file can
> be allowed to be renamed or removed by the server.

Which completely violates the expectations of POSIX applications on the
client. Any idea how you would work around the above?

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com


  reply	other threads:[~2011-08-04  2:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-02 11:58 State of NFSv4 VolatileFilehandles Venkateswararao Jujjuri
2011-08-02 14:53 ` Chuck Lever
2011-08-03  7:28   ` Venkateswararao Jujjuri
2011-08-03 12:27     ` Myklebust, Trond
2011-08-03 22:23       ` NeilBrown
2011-08-04  1:16         ` Malahal Naineni
2011-08-04  2:12           ` Trond Myklebust [this message]
2011-08-15 20:49         ` Malahal Naineni
2011-08-16  8:06           ` Trond Myklebust
2011-08-16 15:59             ` Malahal Naineni
2011-08-16 22:24               ` NeilBrown
2011-08-03 15:43     ` Malahal Naineni
2011-08-03 22:13     ` Chuck Lever
2011-08-04 11:27       ` Venkateswararao Jujjuri
2011-08-04 16:03         ` J. Bruce Fields
2011-08-04 16:10           ` Trond Myklebust
2011-08-04 16:27             ` J. Bruce Fields
2011-08-04 16:48               ` Myklebust, Trond
2011-08-04 17:03                 ` J. Bruce Fields
2011-08-04 17:21                   ` Trond Myklebust
2011-08-04 17:30                     ` J. Bruce Fields
2011-08-04 17:38                       ` Trond Myklebust
2011-08-05 13:38           ` Christoph Hellwig
2011-08-05 19:16             ` J. Bruce Fields
2011-08-10 10:24               ` Christoph Hellwig
2011-08-04 15:56     ` J. Bruce Fields

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=1312423959.2304.10.camel@lade.trondhjem.org \
    --to=trond.myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=malahal@us.ibm.com \
    /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;
as well as URLs for NNTP newsgroup(s).