Re: [PATCH 1/2] [RFC] vfs: 'stat light' fstatat flags

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

 



Hello!

On Apr 7, 2009, at 2:16 PM, Jamie Lokier wrote:

Oleg Drokin wrote:
AT_STRICT allows userspace to indicate that it wants the most up to
date
version of a files status, regardless of performance impact. A
distributed
file system which has a non-coherent inode cache would know then to
send a
direct query to it's server.
Good idea!  Sort out some NFS pain.
If a filesystem doesn't honour AT_STRICT, can we have the function
return an error instead of stale values?
Supposedly the existing stat() is the way to do this?
I don't understand your response.  If an application wants to be sure
it has non-stale attributes, how does stat() help?  Are you saying
stat() does this?  (Afaik it doesn't on NFS).

Well, what the stat actually meant to do is "give me the file information
as it is now". By the time it returns, the data is stale anyway, and the
longer your path from the user app to the actual file storage, the
more potentially out of date the information is.
NFS just takes it to an extreme case and introduces an assumed validity
timeout.
While I do not directly oppose such a flag, I really do not see huge value
in it. I wonder what is the specific usecase do you have in mind?

Bye,
    Oleg
--
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