[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100728111525.355a2bd3@notabene>
Date: Wed, 28 Jul 2010 11:15:25 +1000
From: Neil Brown <neilb@...e.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jan Engelhardt <jengelh@...ozas.de>,
Jeremy Allison <jra@...ba.org>, Volker.Lendecke@...net.de,
David Howells <dhowells@...hat.com>,
linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make
extended file stats available [ver #6]
On Thu, 22 Jul 2010 10:24:17 -0700
Linus Torvalds <torvalds@...ux-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
this value.
Maybe xstat should take a list of xattrs to be retrieved as well?? or maybe
not.
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).
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists