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: utz lehmann on 30 Jul 2010 17:30 On Thu, 2010-07-22 at 09:40 -0700, Linus Torvalds wrote: > 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". When abusing an existing time stamp use atime not ctime please. ctime has it's uses. atime was just a mistake and is nearly useless. And with noatime we already have creation time semantics for atime. utz -- 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: Jeff Layton on 1 Aug 2010 09:30 On Fri, 30 Jul 2010 23:22:58 +0200 utz lehmann <lkml123(a)s2y4n2c.de> wrote: > On Thu, 2010-07-22 at 09:40 -0700, Linus Torvalds wrote: > > 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". > > When abusing an existing time stamp use atime not ctime please. > ctime has it's uses. atime was just a mistake and is nearly useless. > > And with noatime we already have creation time semantics for atime. > Ugh. Honestly all of this talk of abusing different time fields seems like craziness to me. It's going to be very hard to do that without breaking *something*. There's also very little reason to do this when xattrs are a much cleaner approach. Neil Brown has put forth a very reasoned justification for putting the birthtime in an xattr. After reading it, I think that makes more sense than anything. It's also something that can be done without any extra infrastructure. If at some point in the future we get an xstat-like syscall then we can always add birthtime to that as well. Ditto for the other fields under discussion (i_generation and the like). -- Jeff Layton <jlayton(a)redhat.com> -- 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: Jeff Layton on 2 Aug 2010 10:50 On Mon, 2 Aug 2010 10:09:49 -0400 Greg Freemyer <greg.freemyer(a)gmail.com> wrote: > > Furthermore, I'll go ahead and propose the following (simple) semantics: > > > > 1) birthtime is initialized to the current time when a new inode is > > created > > > > 2) it's settable via the xattr to an arbitrary value > > > > Either way, the xattr for this ought to be named the same on all > > filesystems. Samba shouldn't need to know or care what the underlying > > filesystem is, as long as it presents the correct xattr. > > > > That should make samba happy, and be reasonably simple to implement. > > Is there any reason to allow birthtime to be set in advance of the > current birthtime? > > ie restore / copy tools clearly need to backdate it, but I'd prefer to > see it not advance-able. > > Greg Why not? Is there a good argument for prohibiting it? We allow people to set mtime in the future. Why not allow the same semantics here? We also have to consider that this may eventually be settable by via networked filesystem interfaces. If the client and server don't have synchronized clocks you may end up with the client getting an error back in some cases if you don't allow it. -- Jeff Layton <jlayton(a)redhat.com> -- 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 5 Aug 2010 20:00 On Sun, Aug 01, 2010 at 09:25:29AM -0400, Jeff Layton wrote: > On Fri, 30 Jul 2010 23:22:58 +0200 > utz lehmann <lkml123(a)s2y4n2c.de> wrote: > > > On Thu, 2010-07-22 at 09:40 -0700, Linus Torvalds wrote: > > > 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". > > > > When abusing an existing time stamp use atime not ctime please. > > ctime has it's uses. atime was just a mistake and is nearly useless. > > > > And with noatime we already have creation time semantics for atime. > > > > Ugh. Honestly all of this talk of abusing different time fields seems > like craziness to me. It's going to be very hard to do that without > breaking *something*. There's also very little reason to do this when > xattrs are a much cleaner approach. > > Neil Brown has put forth a very reasoned justification for putting the > birthtime in an xattr. After reading it, I think that makes more sense > than anything. It's also something that can be done without any extra > infrastructure. If at some point in the future we get an xstat-like > syscall then we can always add birthtime to that as well. Just my 2 cents (as a Samba server implementor). I *hate* the idea of adding a "virtual" EA for birthtime. If you're going to add it, just add it to the stat struct like *BSD does. Don't abuse the other time fields, it's a new one. Jeff, please don't advocate for an EA for the Samba server to use. Don't add it as an EA. It's *not* an EA, it's a timestamp. 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: Neil Brown on 5 Aug 2010 23:40
On Thu, 5 Aug 2010 16:52:18 -0700 Jeremy Allison <jra(a)samba.org> wrote: > On Sun, Aug 01, 2010 at 09:25:29AM -0400, Jeff Layton wrote: > > On Fri, 30 Jul 2010 23:22:58 +0200 > > utz lehmann <lkml123(a)s2y4n2c.de> wrote: > > > > > On Thu, 2010-07-22 at 09:40 -0700, Linus Torvalds wrote: > > > > 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". > > > > > > When abusing an existing time stamp use atime not ctime please. > > > ctime has it's uses. atime was just a mistake and is nearly useless. > > > > > > And with noatime we already have creation time semantics for atime. > > > > > > > Ugh. Honestly all of this talk of abusing different time fields seems > > like craziness to me. It's going to be very hard to do that without > > breaking *something*. There's also very little reason to do this when > > xattrs are a much cleaner approach. > > > > Neil Brown has put forth a very reasoned justification for putting the > > birthtime in an xattr. After reading it, I think that makes more sense > > than anything. It's also something that can be done without any extra > > infrastructure. If at some point in the future we get an xstat-like > > syscall then we can always add birthtime to that as well. > > Just my 2 cents (as a Samba server implementor). I *hate* the idea > of adding a "virtual" EA for birthtime. If you're going to add it, > just add it to the stat struct like *BSD does. Don't abuse the other > time fields, it's a new one. > > Jeff, please don't advocate for an EA for the Samba server to use. > Don't add it as an EA. It's *not* an EA, it's a timestamp. I'm curious. Why do you particularly care what interface the kernel uses to provide you with access to this attribute? And given that it is an attribute that is not part of 'POSIX' or "UNIX", it would seem to be an extension - an extended attribute. As the Linux kernel does virtually nothing with this attribute except provide access, it seems to be a very different class of thing to other timestamps. Surely it is simply some storage associated with a file which is capable of storing a timestamp, which can be set or retrieved by an application, and which happens to be initialised to the current time when a file is created. Yes, to you it is a timestamp. But to Linux it is a few bytes of user-settable metadata. Sounds like an EA to me. Or do you really want something like BSD's 'btime' which as I understand it cannot be set. Would that be really useful to you? Is there something important that I am missing? 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/ |