Re: [PATCH RFC] vfs: make fstatat retry on ESTALE errors fromgetattr call

[Jeff Layton]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/