From: Sage Weil on
On Tue, 29 Jun 2010, David Howells wrote:
> Ulrich Drepper <drepper(a)gmail.com> wrote:
>
> > On Tue, Jun 29, 2010 at 13:03, David Howells <dhowells(a)redhat.com> wrote:
> > > Add a pair of system calls to make extended file stats available,
> > > including file creation time, inode version and data version where
> > > available through the underlying filesystem:
> >
> > If you add something like this you might want to integrate another
> > extension. This has been discussed a long time ago. In almost no
> > situation all the information is needed. Some of the pieces of
> > information returned by the syscall might be harder to collect than
> > other.
>
> Trond mentioned this:
>
> There has been a lot of interest in allowing the user to specify
> exactly which fields they want the filesystem to return, and whether
> or not the kernel can use cached data or not. The main use is to allow
> specification of a 'stat light' that could help speed up
> "readdir()+multiple stat()" type queries. At last year's Filesystem
> and Storage Workshop, Mark Fasheh actually came up with an initial
> design:
>
> http://www.kerneltrap.com/mailarchive/linux-fsdevel/2009/4/7/5427274
>
> It'd be easy enough to absorb the functionality from that patch.

That would be nice. HPC folks have been looking for this functionality
for some time now.

> > It makes sense in such a situation to allow the caller to specify what she
> > is interested in. A bitmask of some sort.
>
> I have one of those. See the query_flags field. One question, though, is how
> to break things down. Obvious groupings of the already extant stat stuff
> might be:
>
> - st_dev, st_ino, st_mode, st_nlink, st_uid, st_gid, st_rdev, st_size
> - st_block, st_blksize
> - st_atime, st_mtime, st_ctime
>
> However, what seems obvious to me might not be for some netfs or other.

The problem is that groupings that may seem logical now may not match
reality for some specific file system for various implementation reasons.
IMO a bit per field makes the most sense, with some simple way to include
all fields (-1 or 0). A mask argument that is separate from flags might
make that simpler?

sage
--
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: Joel Becker on
On Tue, Jun 29, 2010 at 11:36:56PM +0100, David Howells wrote:
> Ulrich Drepper <drepper(a)gmail.com> wrote:
> > And while you're at it, maybe some spare fields at the end are nice.
>
> I made it so that the syscall can return variable length data: the main xstat
> struct, plus extra records yet to be defined. They could even be variable
> length and assembled/disassembled with something like the control message
> macros for recvmsg().

The less variable length stuff the better, I think. At least,
for the stuff stat(2) already returns, you should have a fixed-size
structure. Even if I only pass the GIVE_ME_UIDS flag, I don't want to
have to deal with the variable size stuff until I've actually asked for
esoteric things. I'll know that the non-UIDS fields are garbage by the
fact that I didn't ask for them.

Joel

--

"Time is an illusion, lunchtime doubly so."
-Douglas Adams

Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker(a)oracle.com
Phone: (650) 506-8127
--
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: Joel Becker on
On Wed, Jun 30, 2010 at 12:29:52AM +0100, David Howells wrote:
> Joel Becker <Joel.Becker(a)oracle.com> wrote:
>
> > The less variable length stuff the better, I think. At least,
> > for the stuff stat(2) already returns, you should have a fixed-size
> > structure. Even if I only pass the GIVE_ME_UIDS flag, I don't want to
> > have to deal with the variable size stuff until I've actually asked for
> > esoteric things. I'll know that the non-UIDS fields are garbage by the
> > fact that I didn't ask for them.
>
> I was thinking of the fixed length xstat struct plus appendable extensions to
> be defined later.

I meant this.

Joel

--

Life's Little Instruction Book #267

"Lie on your back and look at the stars."

Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker(a)oracle.com
Phone: (650) 506-8127
--
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/