2008-01-27 15:55:58

by Erez Zadok

[permalink] [raw]
Subject: [NFS] Q: directory renames and cache coherency in NFS?

NFS shares some traits with stackable file systems. Both have some notion
of "layers": in nfs, it's client -> server -> local f/s; in a stackable f/s
it's upper -> lower.

I'm trying to understand what are the semantics of NFS when directories are
renamed on the server while a client is trying to use those directories (I
follow a similar behavior in unionfs or other stackable f/s). Consider this
sequence of steps:

1. client looks up (or revalidates) directory D1
2. server renames D1 to D2 (D2 could be anywhere in the tree)
3. client tries to create file F in (the cached) directory D1

What happens in the last step? Does the client get an ESTALE or some other
error? Or does it succeed and F gets created in the renamed directory
(D2/F)? Does the behavior differ b/t nfsv2/3/4? Is it described the RFCs
or specs?

Thanks,
Erez.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs



2008-01-27 18:22:51

by Myklebust, Trond

[permalink] [raw]
Subject: Re: [NFS] Q: directory renames and cache coherency in NFS?


On Sun, 2008-01-27 at 10:55 -0500, Erez Zadok wrote:
> NFS shares some traits with stackable file systems. Both have some notion
> of "layers": in nfs, it's client -> server -> local f/s; in a stackable f/s
> it's upper -> lower.
>
> I'm trying to understand what are the semantics of NFS when directories are
> renamed on the server while a client is trying to use those directories (I
> follow a similar behavior in unionfs or other stackable f/s). Consider this
> sequence of steps:
>
> 1. client looks up (or revalidates) directory D1
> 2. server renames D1 to D2 (D2 could be anywhere in the tree)
> 3. client tries to create file F in (the cached) directory D1
>
> What happens in the last step? Does the client get an ESTALE or some other
> error? Or does it succeed and F gets created in the renamed directory
> (D2/F)? Does the behavior differ b/t nfsv2/3/4? Is it described the RFCs
> or specs?

The general rule is that an NFSv2/v3/v4 client would expect 3 to succeed
(provided that the user has the required permissions).

The only exception would be in the case of NFSv4, if the server has set
the filesystem-wide attribute 'fh_expire_type' to the values
FH4_VOL_RENAME or FH4_VOL_ANY (i.e. volatile filehandles). In that case,
the server may return an NFS4ERR_FHEXPIRED error, in which case the
client is supposed to attempt to recover (though what mechanism it may
use to do that after a rename is a mystery to me - the spec certainly
doesn't attempt to explain).

Trond

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs


2008-01-27 18:29:50

by Erez Zadok

[permalink] [raw]
Subject: Re: [NFS] Q: directory renames and cache coherency in NFS?

In message <[email protected].gmane.org>, Trond Myklebust writes:
>
> On Sun, 2008-01-27 at 10:55 -0500, Erez Zadok wrote:
> > NFS shares some traits with stackable file systems. Both have some notion
> > of "layers": in nfs, it's client -> server -> local f/s; in a stackable f/s
> > it's upper -> lower.
> >
> > I'm trying to understand what are the semantics of NFS when directories are
> > renamed on the server while a client is trying to use those directories (I
> > follow a similar behavior in unionfs or other stackable f/s). Consider this
> > sequence of steps:
> >
> > 1. client looks up (or revalidates) directory D1
> > 2. server renames D1 to D2 (D2 could be anywhere in the tree)
> > 3. client tries to create file F in (the cached) directory D1
> >
> > What happens in the last step? Does the client get an ESTALE or some other
> > error? Or does it succeed and F gets created in the renamed directory
> > (D2/F)? Does the behavior differ b/t nfsv2/3/4? Is it described the RFCs
> > or specs?
>
> The general rule is that an NFSv2/v3/v4 client would expect 3 to succeed
> (provided that the user has the required permissions).
[...]

And by "succeed", you mean that the new file F will be created in D2, right?

Thanks,
Erez.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs