On Tue, 2009-04-07 at 13:41 -0400, Oleg Drokin wrote:
> Hello!
>
> On Apr 7, 2009, at 1:32 PM, Jamie Lokier wrote:
>
> > Oleg Drokin wrote:
> >> I have separated stat fields into arbitrary categories based on my
> >> idea of how this needs to be done,
> >> that could of course be refined in other ways if desired.
> > Type should get its own category - which is finer grained than mode.
> > Type (dir, file, link, etc.) is sometimes a lot cheaper than the other
> > attributes to get, because on some filesystems you don't need to read
> > the inode to get the type. See readdir() and d_type.
>
> Sure. In fact I not believe a flag per field would be the way.
>
> > 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.
>
> Sure. When they append to sturct stat, they would add new bits.
> We have 32 bits in the flags, then 3 bits are already used for AT*
> flags.
> That leaves us with 29 bits for STAT_* (or perhaps AT_STAT) flags, and
> we already use ~15 fields in the struct stat, do we have enough bits,
> or should we increase the flags width right now while we are at it?
>
You could introduce one xattr for each field and a getxattrvec() syscall
which returns multiple xattrs.
e.g.
struct attrvec
{
const char * name; /* attribute name */
void * value; /* attribute value buffer */
size_t size; /* size of value buffer */
error_t error; /* error -- 0, ENOATTR, ERANGE, etc. */
};
int getxattrvec(const char *path, struct attrvec *attrs, size_t avcount);
time_t mtime;
mode_t mode;
off_t size;
struct attrvec av[] = {
{ "system.st_mtime", &mtime, sizeof (mtime), 0 },
{ "system.st_mode", &mode, sizeof (mode), 0 },
{ "system.st_size", &size, sizeof (size), 0 }
}
getxattrvec("somefile", av, ARRAY_SIZE(av));
Although, I suspect coalescing multiple xattr requests into a single fs
RPC may get messy.
--
Nicholas Miell <nmiell@xxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
