xstat: Add a pair of system calls to make extended file stats available [ver #6]
in [Kernel]
|
Prev: keypad/nuc900: change keypad driver name from 'nuc900-keypad' to 'nuc900-kpi'
Next: - Mapping ACPI tables as CACHED
From: Jan Engelhardt on 22 Jul 2010 11:50 On Thursday 2010-07-22 17:14, Linus Torvalds wrote: >>> >>> It is? It's called crtime in Ext4. st_btime, however, would be compatible >>> with BSD's stat, and Samba would just use it by way of autoconf magic if it >>> appeared. >> >> Samba has the following check: >> # recent FreeBSD, NetBSD have creation timestamps called birthtime: >> AC_CHECK_MEMBERS([struct stat.st_birthtimespec.tv_nsec]) >> AC_CHECK_MEMBERS([struct stat.st_birthtime], AC_CHECK_MEMBERS([struct stat.st_birthtimensec])) >> >> and the supporting code around that. "birth" might also be >> where the "b" comes from :-) > >Oh wow. And all of this just convinces me that we should _not_ do any >of this, since clearly it's all totally useless and people can't even >agree on a name. > >Let's wait five years and see if there is actually any consensus on it >being needed and used at all, rather than rush into something just >because "we can". There just is no way currently to store creation times. Abusing ctimes for write-once archives also stops working once you rsync it from one place to another. (Which brings me to the side question of why the ctime isn't settable through futimesnat.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jan Engelhardt on 22 Jul 2010 12:30 On Thursday 2010-07-22 17:47, Linus Torvalds wrote: >On Thu, Jul 22, 2010 at 8:36 AM, Volker Lendecke ><Volker.Lendecke(a)sernet.de> wrote: >> >> The nice thing about this is also that if this is supposed >> to be fully usable for Windows clients, the birthtime needs >> to be changeable. That's what NTFS semantics gives you, thus >> Windows clients tend to require it. > >Ok. So it's not really a creation date, exactly the same way ctime >isn't at all a creation date. [...] >Tell me why we shouldn't just do this right? Nobody said the c in ctime stands for creation. It stands for change (you probably knew that). $ touch this $ stat this File: `this' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fh/15d Inode: 106777647 Links: 1 Access: (0644/-rw-r--r--) Uid: (25121/ jengelh) Gid: ( 100/ users) Access: 2010-07-22 18:18:52.665480058 +0200 Modify: 2010-07-22 18:18:52.665480058 +0200 Change: 2010-07-22 18:18:52.665480058 +0200 # Only change inode, not content $ chmod 600 this $ stat this File: `this' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fh/15d Inode: 106777647 Links: 1 Access: (0600/-rw-------) Uid: (25121/ jengelh) Gid: ( 100/ users) Access: 2010-07-22 18:18:52.665480058 +0200 Modify: 2010-07-22 18:18:52.665480058 +0200 Change: 2010-07-22 18:18:58.533436339 +0200 (Solaris exhibits the very same kind of behavior.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jan Engelhardt on 22 Jul 2010 13:10 On Thursday 2010-07-22 18:40, Linus Torvalds wrote: >On Thu, Jul 22, 2010 at 9:27 AM, Jeremy Allison <jra(a)samba.org> wrote: >> On Thu, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote: >>> Tell me why we shouldn't just do this right? >> >> No, ctime isn't the same as Windows "create time". > >Umm. What kind of reading problems do you guys have? > >I know effin well that ctime isn't the same as Windows create time. >THAT WAS MY POINT. > >But the fact is, th Unix ctime semantics are insane and largely >useless. There's a damn good reason almost nobody uses ctime under >unix. I beg to differ. ctime is not completely useless. It reflects changes on the inode for when you don't you change the content. It's like an mtime for the metadata. It comes useful when you go around in your filesystem trying to figure out who of your co-admins screwed up the permissions on /etc/passwd... and if the mtime is the same as that of the last backup, I can at least have a reasonable assurance that it was /only/ the metadata that was tampered with. (SHA1 check, yeah yeah, costly on large files.) >I personally think that Unix ctime is insane. There is no real reason >why "write()" should change mtime, but "chmod" changes ctime. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jan Engelhardt on 22 Jul 2010 14:10 On Thursday 2010-07-22 20:02, Jeremy Allison wrote: >On Thu, Jul 22, 2010 at 12:58:50PM -0400, Trond Myklebust wrote: >> >> That would make it impossible to export the filesystem with NFSv2 and >> v3. They do rely on ctime checking for certain operations (e.g. deciding >> when to invalidate access and acl caches). NFSv4 needs this too if the >> filesystem has no dedicated change attribute. >> >> Still, I suppose the market for exporting the same filesystem with both >> NFS and Samba is limited... > >Ask NetApp about that :-). They have built a rather large >business on just that fact :-). What would ZFS do? :p -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: John Stoffel on 22 Jul 2010 15:30
>>>>> "Jeremy" == Jeremy Allison <jra(a)samba.org> writes: Jeremy> On Thu, Jul 22, 2010 at 12:58:50PM -0400, Trond Myklebust wrote: >> >> That would make it impossible to export the filesystem with NFSv2 and >> v3. They do rely on ctime checking for certain operations (e.g. deciding >> when to invalidate access and acl caches). NFSv4 needs this too if the >> filesystem has no dedicated change attribute. >> >> Still, I suppose the market for exporting the same filesystem with both >> NFS and Samba is limited... Jeremy> Ask NetApp about that :-). They have built a rather large Jeremy> business on just that fact :-). And it does work, as long as you also go with either unix or windows semantics for the security and permissions bits. If you try to use the mixed-mode, you're in for a world of hurt. Oh yeah, Netapp still uses dump/restore for it's backups. :] Though whether it's still dependent on the optimization of ctime being used to know whether to just dump the inode only or not, I can't say. John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |