Re: Attempt at "stat light" implementation

Re: Attempt at "stat light" implementation

[Jeff Garzik]

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

Re: Attempt at "stat light" implementation

[Jamie Lokier]

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

Re: Attempt at "stat light" implementation

[Andreas Dilger]

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.

Re: Attempt at "stat light" implementation

[Ulrich Drepper]

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.

Re: Attempt at "stat light" implementation

[Jamie Lokier]

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