From: Nicholas Miell <nmiell@comcast.net>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: Jamie Lokier <jamie@shareable.org>, linux-fsdevel@vger.kernel.org
Subject: Re: Attempt at "stat light" implementation
Date: Tue, 07 Apr 2009 11:31:44 -0700 [thread overview]
Message-ID: <1239129104.32425.39.camel@entropy> (raw)
In-Reply-To: <0891A741-6527-4BDE-9F6C-FD8FAA45E2F1@linuxhacker.ru>
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@comcast.net>
next prev parent reply other threads:[~2009-04-07 18:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-07 6:23 Attempt at "stat light" implementation Oleg Drokin
2009-04-07 10:23 ` Andreas Dilger
2009-04-07 14:54 ` Oleg Drokin
2009-04-07 17:52 ` Christoph Hellwig
2009-04-07 15:22 ` jim owens
2009-04-07 15:38 ` Oleg Drokin
2009-04-07 16:20 ` jim owens
2009-04-07 17:32 ` Jamie Lokier
2009-04-07 17:38 ` 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
2009-04-07 17:41 ` Oleg Drokin
2009-04-07 17:54 ` Jamie Lokier
2009-04-07 18:00 ` Oleg Drokin
2009-04-07 18:18 ` Andreas Dilger
2009-04-07 18:31 ` Nicholas Miell [this message]
2009-04-07 17:49 ` Christoph Hellwig
2009-04-07 17:56 ` Oleg Drokin
2009-04-07 18:28 ` Andreas Dilger
2009-04-07 18:50 ` Jamie Lokier
2009-04-07 19:48 ` Jeff Garzik
2009-04-07 19:47 ` Jeff Garzik
2009-04-07 20:18 ` Evgeniy Polyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1239129104.32425.39.camel@entropy \
--to=nmiell@comcast.net \
--cc=green@linuxhacker.ru \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.