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: Neil Brown on 7 Aug 2010 07:10 On Sat, 7 Aug 2010 06:34:00 -0400 Jeff Layton <jlayton(a)samba.org> wrote: > On Sat, 7 Aug 2010 13:32:40 +1000 > Neil Brown <neilb(a)suse.de> wrote: > > > So we are left with an attribute that is needed for windows compatibility, > > and so just needs to be understood by samba and wine. Some filesystems might > > support it efficiently, others might require the use of generic > > extended-attributes, still others might not support it at all (I guess you > > store it in some 'tdb' and hope it works well enough). > > > > Core-linux doesn't really need to know about this - there just needs to be a > > channel to pass it between samba/wine and the filesystem. xattr still seems > > the best mechanism to pass this stuff around. Team-samba can negotiate with > > fs developers to optimise/accelerate certain attributes, and linux-VFS > > doesn't need to know or care (except maybe to provide generic non-blocking or > > multiple-access interfaces). > > > > IIUC, you're saying that we should basically just have samba stuff the > current time into an xattr when it creates the file and leave the > filesystems alone. If so, I disagree here. I'm not quite saying that (though there is a temptation). Some attributes are initialised by the filesystem rather than by common code. i_uid is a simple example. I have no problem with the filesystem initialising the storage that is used for this well-known-EA to the current time at creation. This would be part of what team-samba negotiated with FS developers. > > The problem with treating this as *just* an xattr is that it doesn't > account for files that are created outside of samba but are then shared > out by it. If something is created in a different universe, then brought into this one - when is its date of birth? The moment of creation, or the moment of entry into this universe? If both universes have a common time line (altough with a 10 year offset) then I guess the former, though I think it is a bit of a philosophical point.... :-) > > To handle this correctly, I believe it needs to be initialized by the > kernel to the current time whenever an inode is created, even if samba > doesn't create it. After that, it can be treated as just another xattr. > Yes, I suspect that would be ideal, and trivial for the fs to implement (it has to initialise it to something after all). i.e. I agree. 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/
From: Jeremy Allison on 8 Aug 2010 08:20 On Fri, Aug 06, 2010 at 01:38:36PM +1000, Neil Brown wrote: > I'm curious. Why do you particularly care what interface the kernel uses to > provide you with access to this attribute? It's a matter of taste. The *BSD's have this right IMHO. It should be part of the stat information. A file timestamp is not an EA. Making it available that way just feels like an appalingly tasteless kludge. It offends the artist in 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? It is *already* useful to us, and is widely used in existing code. The occasions when btime is set are relatively rare, and at that point we store it in a separate EA for Windows reporting purposes. 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: Jeff Layton on 8 Aug 2010 09:00 On Sun, 8 Aug 2010 05:12:09 -0700 Jeremy Allison <jra(a)samba.org> wrote: > On Fri, Aug 06, 2010 at 01:38:36PM +1000, Neil Brown wrote: > > I'm curious. Why do you particularly care what interface the kernel uses to > > provide you with access to this attribute? > > It's a matter of taste. The *BSD's have this right IMHO. It > should be part of the stat information. A file timestamp is not > an EA. Making it available that way just feels like an appalingly > tasteless kludge. It offends the artist in me :-). > It would be more convenient if this were part of stat() but adding a new stat call is non-trivial. Even if we did that, it still doesn't solve the problem of being able to set the create time. The fact that that's rarely done doesn't really matter much -- we ought to shoot for the semantics that are needed to handle this properly. If we do settle on a xstat() interface, it might also end up being able to report things like selinux labels which are also available and settable via xattr. I don't see a problem with presenting the same data via multiple interfaces. If presenting this data via xattr solves the immediate problem of being able to properly store and report the create time then it seems like a win. > > 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? > > It is *already* useful to us, and is widely used in > existing code. The occasions when btime is set are > relatively rare, and at that point we store it in a > separate EA for Windows reporting purposes. > If that's the case, don't you have to query for this EA every time you need to return the create time anyway? If so, then doing this really isn't any more costly -- you'd just be querying a different EA, right? -- 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 8 Aug 2010 09:10 On Sun, Aug 08, 2010 at 08:53:01AM -0400, Jeff Layton wrote: > > It would be more convenient if this were part of stat() but adding a > new stat call is non-trivial. Even if we did that, it still doesn't > solve the problem of being able to set the create time. The fact that > that's rarely done doesn't really matter much -- we ought to shoot for > the semantics that are needed to handle this properly. *BSD didn't. They just added something that was useful to UNIX. I'd be happy with that. We don't need to ape Windows in everything. The coming ACL disaster will show that (we will go from an ACL model that is slightly too complex to use, to one that is impossibly complex to use :-). > If that's the case, don't you have to query for this EA every time you > need to return the create time anyway? If so, then doing this really > isn't any more costly -- you'd just be querying a different EA, right? No, we'd be querying an additional EA. The EA we query contains the DOS attribues as well as the create time. 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 8 Aug 2010 19:10
On Sun, 8 Aug 2010 05:12:09 -0700 Jeremy Allison <jra(a)samba.org> wrote: > On Fri, Aug 06, 2010 at 01:38:36PM +1000, Neil Brown wrote: > > I'm curious. Why do you particularly care what interface the kernel uses to > > provide you with access to this attribute? > > It's a matter of taste. The *BSD's have this right IMHO. It > should be part of the stat information. A file timestamp is not > an EA. Making it available that way just feels like an appalingly > tasteless kludge. It offends the artist in me :-). Unfortunately whenever you work on a collaborative project someone has to make concessions to taste, as we all taste different.. (or have different taste.. or something). So I think it is very important to clearly differentiate the practical issues from the aesthetic issues as I think we can hope for unity on the former, but never on the latter. > > > 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? > > It is *already* useful to us, and is widely used in > existing code. The occasions when btime is set are > relatively rare, and at that point we store it in a > separate EA for Windows reporting purposes. I'm probably sounding like a scratched record, but when you say "is widely used" do you mean "is used in samba which is widely used" or do you mean "is used in a wide variety of applications"? Because if you are only saying the former, then I don't think we should copy BSD, but rather I think we should provide exactly the semantics that are most useful to samba - and that would seem to be creation-time and DOS flags which the filesystem can store directly in the inode and which samba can access cheaply. (and I would prefer to use xattrs, but that is a taste thing and as I'm not writing the code, I don't get to choose the taste). But if you are saying the later, then sharing those details might help us see that copying bsd is actually the best thing to do, or maybe that something else is better. I'm just afraid that if some new interface is added without clear, comprehensive and up-front justification then we will end up getting a sub-optimal interface. 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/ |