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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes:

> On Tue, Apr 17, 2012 at 10:20:35AM -0400, Jeff Layton wrote:
>> 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
>
> For "filehandle" I'd specify "current and saved filehandle".
>
>> that it does not go stale over the life of the compound."
>
> And that's *much* less of a burden on the server than requiring that the
> compound execute atomically.
>
>> ...or something along those lines. That's a different matter though and
>> not directly related to this. :)
>
> Yes.

It's only related, because it proves that it's theoretically possible to
deal with this problem without introducing infinite retries.  And that
applies to all operations, not just getattr.

As for atomicity, the VFS doesn't have any atomicity guarantees here
either.  So for example getattr("foo") may end up with st_nlink == 0
with a concurrent rename("bar", "foo").  Whether this is permitted by
the standards is another matter, but it's not something that appears to
bother anybody.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux