xstat: Add a pair of system calls to make extended file stats available [ver #6]
in [Kernel]
|
Prev: [PATCH 1/1] VIDEO: ivtvfb, remove unneeded NULL test
Next: [PATCH] i8042: add Gigabyte Spring Peak to dmi_noloop_table
From: Linus Torvalds on 19 Jul 2010 13:50 On Mon, Jul 19, 2010 at 10:26 AM, David Howells <dhowells(a)redhat.com> wrote: > >> Ask your samba people, for example, if they'd _ever_ do just a "xstat()"? > > I suspect they would, though maybe they can say otherwise. �What about SMB > directory enumeration? �I believe that is effectively getdents-with-stat. > Having to do open+stat for each file for that would be painful. Yeah, but do you need xstat information at all for something like that? Most people try very hard to make do with the information returned by readdir itself (d_type and inode number), because if you end up looking up each name you've already pretty much lost in a performance model. (And I do agree that a "readdirplus()" is probably something that a lot of server people would find useful, but obviously that's another cross-filesystem nightmare. Only a few filesystems can cheaply give you anything but d_type/d_ino, and not all do even that), Linus -- 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: Linus Torvalds on 22 Jul 2010 11:20 On Thu, Jul 22, 2010 at 5:17 AM, Volker Lendecke <Volker.Lendecke(a)sernet.de> wrote: > On Thu, Jul 22, 2010 at 01:14:47PM +0100, David Howells wrote: >> Jan Engelhardt <jengelh(a)medozas.de> wrote: >> >> > Linux already has a creation time field, it's called otime (there is no "b" >> > in "creation"), and you will find scattered fragments of that all over the >> > kernel (foremost, fs/jfs/, now btrfs, and I also notice sysvipc having >> > something with that name). >> >> 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". Linus -- 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: Linus Torvalds on 22 Jul 2010 11:50 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. And maybe that actually hints at a better solution: maybe a better model is to create a new per-thread flag that says "do ctime updates the way windows does them". So instead of adding another "btime" - which isn't actually what even windows does - just admit that the _real_ issue is that Unix and Windows semantics are different for the pre-existing "ctime". The fact is, windows has "access time", "modification time" and "creation time" _exactly_ like UNIX. It's just that the ctime has slightly different semantics in windows vs unix. So quite frankly, it's totally insane to introduce a "birthtime", when that isn't even what windows wants, just because people cannot face the actual real difference. Tell me why we shouldn't just do this right? Linus -- 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: Greg Freemyer on 22 Jul 2010 12:10 On Thu, Jul 22, 2010 at 12:06 PM, Greg Freemyer <greg.freemyer(a)gmail.com> wrote: > On Thu, Jul 22, 2010 at 11:47 AM, Linus Torvalds > <torvalds(a)linux-foundation.org> 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. >> >> And maybe that actually hints at a better solution: maybe a better >> model is to create a new per-thread flag that says "do ctime updates >> the way windows does them". >> >> So instead of adding another "btime" - which isn't actually what even >> windows does - just admit that the _real_ issue is that Unix and >> Windows semantics are different for the pre-existing "ctime". >> >> The fact is, windows has "access time", "modification time" and >> "creation time" _exactly_ like UNIX. It's just that the ctime has >> slightly different semantics in windows vs unix. So quite frankly, >> it's totally insane to introduce a "birthtime", when that isn't even >> what windows wants, just because people cannot face the actual real >> difference. >> >> Tell me why we shouldn't just do this right? >> >> � � � � � � � �Linus > > I haven't been keeping up with this thread, but I believe NTFS has a > number of timestamps, not just 3. > > This blog post references 8 in the left hand column. > > The 4 standard (most common) ones are: > > File last access > File last modified > File created > MFT last modified > > My understanding is that "MFT last modified" has semantics very > similar to Linux ctime. > > But there is not a generic equivalent to NTFS created. > > Thus if trying to have the Linux kernel match NTFS semantics for the > benefit of Samba is the goal, it seems a new field should be preferred > instead of having linux ctime try to do different jobs. > > Greg I forgot the blog post url: http://blogs.sans.org/computer-forensics/2010/04/12/windows-7-mft-entry-timestamp-properties/ -- 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: Linus Torvalds on 22 Jul 2010 12:50
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. So what I'm suggesting is that we have a flag - either per-process or per-mount - that just says "use windows semantics for ctime". And yes, I'm very aware that the "c" in ctime doesn't stand for "create". But anybody who points that out is - once more - totally missing the point. My point is that we have three timestamps, and windows wants three timestamps (somebody claims that NTFS has four timestamps, but the Windows file time access functions certainly only shows three times, so any potential extra on-disk times have no relevance because they are invisible to pretty much everybody). We can have unix semantics for mtime/atime/ctime, or we can have windows semantics for those three values. So let's say that we introduce a mount flag that says "ctime=winctime", which basically just sets a flag that instead of changing ctime on chmod/chown/etc, it just changes mtime instead (or, as mentioned, we could make it a process flag instead). Let's face it, Unix semantics are not sacred. Especially not something like ctime, which is pretty damn useless. If you're a samba server, why not just say "let's do ctime the way windows does creation times", and let it be at that? I personally think that Unix ctime is insane. There is no real reason why "write()" should change mtime, but "chmod" changes ctime. It was just a random decision way back when, and it's clearly not what samba wants, and it's equally clearly not what even most _unix_ people want (just google for "ctime" and "creation time", and watch the confusion - exactly because unix semantics are simply _random_ and odd semantics in this area) I would not be at all surprised if it turns out that people might want to really turn ctime into creation time (with the mount flag or whatever) even if they are _not_ running samba. An added issue is that most filesystems simply don't have more than three times (and some obviously have not even that, but that's true in Windows too). So re-using ctime actually means that this scheme would work a whole lot better than some crazy xstat() interface that doesn't support common filesystems anyway. Linus -- 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/ |