[PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]
neilb at suse.de
Tue Jul 27 19:15:25 MDT 2010
On Thu, 22 Jul 2010 10:24:17 -0700
Linus Torvalds <torvalds at linux-foundation.org> wrote:
> Of people can just use xattrs and do it all entirely in user space. I
> assume that's what samba does now, even outside of birthtime.
Much as I despise xattrs, this would definitely be my preference.
ctime and mtime have real cache-coherence semantics which require them being
updated by the kernel (whether the cache is on an NFS client, in a backup
archive, or in a .o translation of a .c file).
create-time, on the other hand, would never be updated by the kernel, and
might sometimes be updated by an application. So it is a very different sort
of attribute, much like a hypothetical 'last archived' time.
The only role the kernel might have would be setting the 'creation time' when
the file was created, but it seems even that isn't always what is wanted,
because people don't so much what the time of create of the
container-on-disk, but the time of creation of the data-content.
I would want to see a pretty convincing use-case that cannot be solved with
xattrs before 'creation time' was added to a generic kernel interface.
So just use xattrs and don't involve the kernel in any detailed knowledge of
Maybe xstat should take a list of xattrs to be retrieved as well?? or maybe
But I hope the xstat debate doesn't get bogged down about whether 'create
time' is sensible or not. Quite apart from the ability to return more
attributes, I think it has real value is being able to return fewer
attributes, and being allowed to ask for 'best guess' values. Being able to
do an 'fstat' and being certain that you won't be blocked by a non-responsive
NFS server would be a GOOD THING (TM).
More information about the samba-technical