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: Wed, 02 Jul 2008 00:33:31 -0600 Message-ID: <20080702063331.GQ6239@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> <20080626165618.GP6239@webber.adilger.int> <1DAFD0EF-FF4A-456C-A7E6-E718031E220D@cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: Jamie Lokier , Eric Sandeen , Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Josef Bacik To: Anton Altaparmakov Return-path: Received: from sca-es-mail-2.Sun.COM ([192.18.43.133]:60034 "EHLO sca-es-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762331AbYGBGdh (ORCPT ); Wed, 2 Jul 2008 02:33:37 -0400 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m626XYr4010909 for ; Tue, 1 Jul 2008 23:33:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3D00F018RJ1600@fe-sfbay-10.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Tue, 01 Jul 2008 23:33:34 -0700 (PDT) In-reply-to: <1DAFD0EF-FF4A-456C-A7E6-E718031E220D@cam.ac.uk> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jun 29, 2008 20:12 +0100, Anton Altaparmakov wrote: >> 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). > > But how would you return multiple xattrs if some of them are stored > inside the on-disk inode structure, some are stored in a single extent, > and some are stored in lots of extents, i.e. some have "proper", > block-aligned mappings and some don't. The ext4 code can also have both in-inode and external xattr data. If the inode has data in both locations it will return two extents, each one with a separate set of flags. > This is the case for NTFS where > each xattr is stored as a named stream and each named stream is treated > in exactly the same way as the file data itself (which is simply an > unnamed named stream, i.e. a named stream with a filename length of zero) > thus each xattr is stored independently and depending on their sizes you > can end up with multiple xattrs inside the same on-disk block and you can > also end up with a huge xattr that has a really large number of extents > (the maximum size of each xattr/named stream in NTFS is 2^63-1 bytes > which is really rather big)... The XATTR request is really only intended for the "small" getxattr data. If there are large "xattrs" (i.e. data forks) then I'd suggest instead to use openat() to open the data fork and call FIEMAP on that directly. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.