* Re: Attempt at "stat light" implementation [not found] ` <20090407173248.GC31824@shareable.org> @ 2009-04-07 17:38 ` Jeff Garzik 2009-04-07 17:56 ` Jamie Lokier 0 siblings, 1 reply; 5+ messages in thread From: Jeff Garzik @ 2009-04-07 17:38 UTC (permalink / raw) To: Jamie Lokier; +Cc: Oleg Drokin, linux-fsdevel, LKML Jamie Lokier wrote: > Once you have fine-grained selection of stat fields - it's natural to > ask why not allow _additional_ stat fields in an future-extensible > fashion? A few things would be handy sometimes, such as inode > generation number, modification generation number (to detect changes > across reboots), and extra flags indicating COW or other properties. That's quite an interesting thought... until you run out of flags, the stat structure becomes a bit more flexible. Jeff ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Attempt at "stat light" implementation 2009-04-07 17:38 ` Attempt at "stat light" implementation Jeff Garzik @ 2009-04-07 17:56 ` Jamie Lokier 2009-04-07 18:21 ` Andreas Dilger 0 siblings, 1 reply; 5+ messages in thread From: Jamie Lokier @ 2009-04-07 17:56 UTC (permalink / raw) To: Jeff Garzik; +Cc: Oleg Drokin, linux-fsdevel, LKML Jeff Garzik wrote: > Jamie Lokier wrote: > >Once you have fine-grained selection of stat fields - it's natural to > >ask why not allow _additional_ stat fields in an future-extensible > >fashion? A few things would be handy sometimes, such as inode > >generation number, modification generation number (to detect changes > >across reboots), and extra flags indicating COW or other properties. > > That's quite an interesting thought... until you run out of flags, the > stat structure becomes a bit more flexible. I suspect at least one other unix or unix-like OS has done this already, and it might be worth copying the interface. But none come to mind. (I'm not counting DJGPP on MS-DOS ;-) -- Jamie ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Attempt at "stat light" implementation 2009-04-07 17:56 ` Jamie Lokier @ 2009-04-07 18:21 ` Andreas Dilger 2009-04-07 19:30 ` Ulrich Drepper 0 siblings, 1 reply; 5+ messages in thread From: Andreas Dilger @ 2009-04-07 18:21 UTC (permalink / raw) To: Jamie Lokier; +Cc: Jeff Garzik, Oleg Drokin, linux-fsdevel, LKML On Apr 07, 2009 18:56 +0100, Jamie Lokier wrote: > Jeff Garzik wrote: > > Jamie Lokier wrote: > > >Once you have fine-grained selection of stat fields - it's natural to > > >ask why not allow _additional_ stat fields in an future-extensible > > >fashion? A few things would be handy sometimes, such as inode > > >generation number, modification generation number (to detect changes > > >across reboots), and extra flags indicating COW or other properties. > > > > That's quite an interesting thought... until you run out of flags, the > > stat structure becomes a bit more flexible. > > I suspect at least one other unix or unix-like OS has done this > already, and it might be worth copying the interface. But none come to > mind. There is one in OS/X called getattrlist, but it is quite complex and would require attribute handling wildly different than what the kernel and *nix applications are doing: http://www.manpagez.com/man/2/getattrlist/ Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Attempt at "stat light" implementation 2009-04-07 18:21 ` Andreas Dilger @ 2009-04-07 19:30 ` Ulrich Drepper 2009-04-12 20:55 ` Jamie Lokier 0 siblings, 1 reply; 5+ messages in thread From: Ulrich Drepper @ 2009-04-07 19:30 UTC (permalink / raw) To: Andreas Dilger Cc: Jamie Lokier, Jeff Garzik, Oleg Drokin, linux-fsdevel, LKML On Tue, Apr 7, 2009 at 11:21 AM, Andreas Dilger <adilger@sun.com> wrote: > There is one in OS/X called getattrlist, but it is quite complex and > would require attribute handling wildly different than what the kernel > and *nix applications are doing: > > http://www.manpagez.com/man/2/getattrlist/ I think this is overkill. There are two different tasks to do: - speed up stat by providing a subset of the information - provide a mechanism to get arbitrary attribute support and efficient ways to get to it Trying to force both of these tasks into one interface will partially defeat the purpose of the first, creating a fast stat replacement. I think these should be different interfaces (if the second type is needed at all). As for making the interface extendable. In all the years there hasn't really been much need to extend the stat structure (ignoring extended attributes). So, I'd not be worried about using a simple 32-bit bitmask to select the fields to include in the fast stat. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Attempt at "stat light" implementation 2009-04-07 19:30 ` Ulrich Drepper @ 2009-04-12 20:55 ` Jamie Lokier 0 siblings, 0 replies; 5+ messages in thread From: Jamie Lokier @ 2009-04-12 20:55 UTC (permalink / raw) To: Ulrich Drepper Cc: Andreas Dilger, Jeff Garzik, Oleg Drokin, linux-fsdevel, LKML Ulrich Drepper wrote: > As for making the interface extendable. In all the years there hasn't > really been much need to extend the stat structure (ignoring extended > attributes). So, I'd not be worried about using a simple 32-bit > bitmask to select the fields to include in the fast stat. I agree about 32 bits being enough. I think there has been some demand for new fields, but it's not been strong enough to justify all the breakage from changing the normal stat structure. That's why we have generic filesystem ioctls: FS_IOC_GETFLAGS, FS_IOC_GETVERSION, which return things which would naturally go with stat if it were free to do so (but it isn't). -- Jamie ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-04-12 20:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20090407062356.GA1336463@fiona.linuxhacker.ru>
[not found] ` <20090407173248.GC31824@shareable.org>
2009-04-07 17:38 ` Attempt at "stat light" implementation Jeff Garzik
2009-04-07 17:56 ` Jamie Lokier
2009-04-07 18:21 ` Andreas Dilger
2009-04-07 19:30 ` Ulrich Drepper
2009-04-12 20:55 ` Jamie Lokier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox