From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: Attempt at "stat light" implementation Date: Tue, 07 Apr 2009 11:21:57 -0700 Message-ID: <20090407182157.GW3204@webber.adilger.int> References: <20090407062356.GA1336463@fiona.linuxhacker.ru> <20090407173248.GC31824@shareable.org> <49DB8F8E.9010605@garzik.org> <20090407175617.GF31824@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: Jeff Garzik , Oleg Drokin , linux-fsdevel@vger.kernel.org, LKML To: Jamie Lokier Return-path: Received: from sca-es-mail-2.Sun.COM ([192.18.43.133]:49281 "EHLO sca-es-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760143AbZDGSWJ (ORCPT ); Tue, 7 Apr 2009 14:22:09 -0400 Content-disposition: inline In-reply-to: <20090407175617.GF31824@shareable.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.