From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Thu, 26 Jun 2008 10:56:18 -0600 Message-ID: <20080626165618.GP6239@webber.adilger.int> References: <20080625221835.GQ28100@wotan.suse.de> <20080626093634.GA30025@shareable.org> <20080626102403.GN6239@webber.adilger.int> <20080626121950.GB32417@shareable.org> <20080626131600.GS29319@disturbed> <48639E2B.4000401@redhat.com> <20080626141649.GD3356@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: Eric Sandeen , Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Josef Bacik To: Jamie Lokier Return-path: Received: from sca-es-mail-1.Sun.COM ([192.18.43.132]:52048 "EHLO sca-es-mail-1.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760656AbYFZSCn (ORCPT ); Thu, 26 Jun 2008 14:02:43 -0400 Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5QGudd1019402 for ; Thu, 26 Jun 2008 09:56:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3200B01W3PYQ00@fe-sfbay-09.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Thu, 26 Jun 2008 09:56:39 -0700 (PDT) In-reply-to: <20080626141649.GD3356@shareable.org> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jun 26, 2008 15:16 +0100, Jamie Lokier wrote: > > > Because xattrs tend to contain user data, not metadata? > > > > Agreed, I don't see anything particularly strange about returning the > > xattr mapping, and to me it's not particularly fs specific (well, the > > detailed format of the on-disk data might be, i.e. the layout of names & > > values within that blob of data, but it is still user data... I guess > > it's something of a grey area). > > I'm thinking that some filesystems won't store it as a 'blob' at all, > but as, for example, leaves in a whole-fs tree structure on the same > footing as permissions, size, etc. > > I don't see a problem with the xattr feature - it might be useful on > several filesystems. (For my own program which tries to call stat() > in disk layout order to reduce seeks, knowing xattr blocks _would_ be > useful, as it could try to get xattrs in disk layout order too). > > I just wanted to bring up that "all the xattrs of one inode" aren't > necessarily a blob of data in the same way as ordinary contents. > (Just in case it's being assumed that it is.) It doesn't need to be a "blob", per se. The physical addresses should really represent where the xattrs are stored on disk, regardless of whether it is stored in a separate block, or in the inode, or in the leaves of a filesystem-wide tree. There can be multiple blocks/extents returned for an XATTR request (as ext4 and ext3 eventually will allow). The logical offset of an xattr doesn't make so much sense, but I don't think that is harmful. I'd suggest that multiple xattrs be returned in the order that a name search would be done, but I don't think it really matters. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.