From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Thu, 26 Jun 2008 15:16:49 +0100 Message-ID: <20080626141649.GD3356@shareable.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andreas Dilger , Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Josef Bacik To: Eric Sandeen Return-path: Received: from mail2.shareable.org ([80.68.89.115]:46073 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751890AbYFZOQv (ORCPT ); Thu, 26 Jun 2008 10:16:51 -0400 Content-Disposition: inline In-Reply-To: <48639E2B.4000401@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > > 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.) -- Jamie