From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nicholas Miell <nmiell@comcast.net>
Subject: Re: Attempt at "stat light" implementation
Date: Tue, 07 Apr 2009 11:31:44 -0700
Message-ID: <1239129104.32425.39.camel@entropy>
References: <20090407062356.GA1336463@fiona.linuxhacker.ru>
	 <20090407173248.GC31824@shareable.org>
	 <0891A741-6527-4BDE-9F6C-FD8FAA45E2F1@linuxhacker.ru>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: Jamie Lokier <jamie@shareable.org>, linux-fsdevel@vger.kernel.org
To: Oleg Drokin <green@linuxhacker.ru>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from qmta10.emeryville.ca.mail.comcast.net ([76.96.30.17]:39091 "EHLO
	QMTA10.emeryville.ca.mail.comcast.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1756485AbZDGSbr (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 7 Apr 2009 14:31:47 -0400
In-Reply-To: <0891A741-6527-4BDE-9F6C-FD8FAA45E2F1@linuxhacker.ru>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

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>