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 - To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
