On Tue, 17 Apr 2012 14:04:34 +0000 "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > On Tue, 2012-04-17 at 09:32 -0400, Jeff Layton wrote: > > On Tue, 17 Apr 2012 15:12:20 +0200 > > Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > To do that would require protocol support that we simply don't have. We > > don't have a way to (for instance) say via NFS "give me the attributes > > for this filename". Well, at least not for NFSv3... > > What's wrong with LOOKUP? > Some of this is due to my decision to use fstatat as an example, but we should bear in mind that I've just been using that as an example. We'll eventually have to do something similar for all path based syscalls in order to fix tihs comprehensively. While it may be possible to handle stat type calls atomically with a simple LOOKUP call, other operations may require more than one round trip. Consider chmod(), for instance... > > With v4 you could theoretically construct a compound that does that, > > but you'd have to assume that the server won't release the reference to > > the inode midway through the compound. That's a reasonably safe > > assumption. > > Actually, NFSv4 is the one that has the problem: there are no atomicity > guarantees within compounds, so you could theoretically get an ESTALE in > the GETATTR part of our lookup compound. > Well, it's possible, but it seems pathological to me for a server to do that... Bruce and I were discussing this the other day. It would be good to add something like this to the RFCs: "On a PUTFH, a server SHOULD hold a reference to the filehandle such that it does not go stale over the life of the compound." ...or something along those lines. That's a different matter though and not directly related to this. :) -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
