xstat: Add a pair of system calls to make extended file stats available [ver #6]
in [Kernel]
|
Prev: perf annotate segfaults when source code has goto label that looks like hex number
Next: [PATCH 4/5] staging: wlags49_h2: remove custom hex_to_bin() method
From: Trond Myklebust on 22 Jul 2010 13:00 On Thu, 2010-07-22 at 09:40 -0700, 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. > > 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. 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... Cheers Trond -- 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: Volker Lendecke on 22 Jul 2010 14:10 On Thu, Jul 22, 2010 at 11:02:04AM -0700, 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 :-). Jeremy, how many hours have you spent getting "posix locking" to the point where it is now? :-) Volker P.S: For those not aware, "posix locking = yes" is cross-protocol byte range locking done by smbd to co-operate with local processes and NFS. -- 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: Jeremy Allison on 22 Jul 2010 14:10 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 :-). Jeremy. -- 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: Trond Myklebust on 22 Jul 2010 15:00 On Thu, 2010-07-22 at 20:04 +0200, Volker Lendecke wrote: > On Thu, Jul 22, 2010 at 11:02:04AM -0700, 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 :-). > > Jeremy, how many hours have you spent getting "posix > locking" to the point where it is now? :-) > > Volker > > P.S: For those not aware, "posix locking = yes" is > cross-protocol byte range locking done by smbd to co-operate > with local processes and NFS. I said "limited", not "non-existent". The fact remains that most of us would be hard pressed to name an application that requires you to share the same dataset to both Windows/CIFS and posix NFS clients. Everything from ACL models through caseless vs case-aware filesystems and Windows vs posix locking semantics tends to discourage mixing the two environments. Trond -- 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: Neil Brown on 27 Jul 2010 21:20
On Thu, 22 Jul 2010 10:24:17 -0700 Linus Torvalds <torvalds(a)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 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(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/ |