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 04:24:03 -0600 Message-ID: <20080626102403.GN6239@webber.adilger.int> References: <20080625221835.GQ28100@wotan.suse.de> <20080626093634.GA30025@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Eric Sandeen , Josef Bacik To: Jamie Lokier Return-path: Received: from sca-es-mail-1.Sun.COM ([192.18.43.132]:35070 "EHLO sca-es-mail-1.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752600AbYFZKYG (ORCPT ); Thu, 26 Jun 2008 06:24:06 -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 m5QAO5I6022255 for ; Thu, 26 Jun 2008 03:24:06 -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 <0K3200C01FEW5400@fe-sfbay-09.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Thu, 26 Jun 2008 03:24:05 -0700 (PDT) In-reply-to: <20080626093634.GA30025@shareable.org> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jun 26, 2008 10:36 +0100, Jamie Lokier wrote: > Mark Fasheh wrote: > > * FIEMAP_FLAG_SYNC > > If this flag is set, the kernel will sync the file before mapping extents. > > Is there a reason why fsync() before calling FIEMAP is unsuitable? This was added because the xfsbmap operation always did an fsync before returning the extents. I don't think it is strictly required, but it isn't harmful either. > > * FIEMAP_FLAG_XATTR > > If this flag is set, the extents returned will describe the inodes > > extended attribute lookup tree, instead of it's data tree. > > What is this for? The meaning of the xattr tree sounds rather > filesystem specific to me. This is to return the location of the xattr blocks for the inode. > > * FIEMAP_EXTENT_NO_DIRECT > > Direct access to the data in this extent is illegal or will have > > undefined results. > ... > > * FIEMAP_EXTENT_NET > > - This will also set FIEMAP_EXTENT_NO_DIRECT > > The data for this extent is not stored in a locally-accessible device. > > Does this _always_ set FIEMAP_EXTENT_NO_DIRECT? Some network > filesystems do support O_DIRECT access - NFS comes to mind. > > (I'm assuming 'direct access' means O_DIRECT). "NO_DIRECT" has nothing to do with "O_DIRECT". It just means that, per the description a few lines earlier, direct access to the file data is impossible (i.e. for lilo or other tool which thinks it can open "dev" and seek to "fe_physical" to read the data), or at best will have undefined results (e.g. you may get encrypted or compressed data back, or it is on the far side of a network interface). > > * FIEMAP_EXTENT_DATA_ENCRYPTED > > - This will also set FIEMAP_EXTENT_NO_DIRECT > > The data in this extent has been encrypted by the file system. > > I don't think encryption necessarily rules out O_DIRECT. It'll depend > how I/O is implemented by that filesystem. > > > * FIEMAP_EXTENT_DATA_INLINE > > This will also set FIEMAP_EXTENT_NOT_ALIGNED > > Data is located within a meta data block. > > This seems like it would always set FIEMAP_EXTENT_NO_DIRECT :-) > > (Generally, won't FIEMAP_EXTENT_NOT_ALIGNED always set > FIEMAP_EXTENT_NO_DIRECT?) > > > * FIEMAP_EXTENT_DATA_TAIL > > This will also set FIEMAP_EXTENT_NOT_ALIGNED > > Data is packed into a block with data from other files. > > Maybe this too. The rest of these comments seem based on the previous misunderstanding. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.