Message-ID: <4C488C41.60002@panasas.com>
Date:	Thu, 22 Jul 2010 21:21:53 +0300
From:	Benny Halevy <bhalevy@...asas.com>
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 Jul. 22, 2010, 20:24 +0300, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Thu, Jul 22, 2010 at 10:03 AM, Jan Engelhardt <jengelh@...ozas.de> wrote:
>>
>> I beg to differ. ctime is not completely useless. It reflects changes on
>> the inode for when you don't you change the content.
> 
> Uh. Yes. Except that why is file metadata really different from file
> data? Most people really don't care. And a lot of people have asked
> for creation dates - and I seriously doubt that Windows people
> complain a lot about the fact that there you have mtime for metadata
> changes too.
> 
> The point being that Unix ctime semantics certainly have well-defined
> semantics, but they are in no way "better" than having a real creation
> time, and are often worse.

Yeah, having create time would be important.
That said, having a non user-settable modify timestamp is crucial
for quickly determining whether a file has changed.

Benny

> 
> Just imagine what you could do as an MIS person if you actually had a
> creation time you could somewhat trust? You talk about seeing somebody
> change the permissions of /etc/passwd, but realistically, absent
> preexisting semantics, who would really ask for that? The only reason
> you mention that as an example of what you can do with ctime is that
> that is indeed pretty much the _only_ thing you can do with ctime, and
> it really isn't that useful.
> 
> In contrast, with a creation date, you see the difference between
> people overwriting files by writing to them, or overwriting files by
> creating a new one and moving it over the old one. At a guess, that
> would be quite as useful to a sysadmin as ctime is now (my gut feel is
> that it would be more so, but whatever).
> 
> IOW, there really isn't anything magically good about UNIX ctime
> semantics, and in fact they are totally broken in the presence of
> extended attributes (that's file data, but it only changes ctime? WTF
> is up with that? Yes, I know why it happens, and it makes sense within
> the insane unix ctime rules, but no way does it make sense in a bigger
> picture unless you are in total denial and try to claim that xattrs
> are just metadata despite having contents).
> 
> And yes, I am also sure that there are applications that do depend on
> ctime semantics. Trond mentioned NFS serving, and that's unfortunate.
> I bet there are others. That's inevitable when you have 40 years of
> history. So I'm not claiming that re-using ctime is painfree, but for
> somebody that cares about samba a lot, I bet it's a _lot_ better than
> adding a new time that almost nobody actually supports as things stand
> now.
> 
> 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.
> 
>                      Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists