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 13:19:51 +0100 Message-ID: <20080626121950.GB32417@shareable.org> References: <20080625221835.GQ28100@wotan.suse.de> <20080626093634.GA30025@shareable.org> <20080626102403.GN6239@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Eric Sandeen , Josef Bacik To: Andreas Dilger Return-path: Received: from mail2.shareable.org ([80.68.89.115]:41315 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761AbYFZMTx (ORCPT ); Thu, 26 Jun 2008 08:19:53 -0400 Content-Disposition: inline In-Reply-To: <20080626102403.GN6239@webber.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Andreas Dilger wrote: > > 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. It's not harmful but suggests it might do something important - e.g. provide atomicity between the fsync and getting extends. Can the documentation make it clear that it's exactly equivalent to calling fsync() before - or, if that's not true, explain the diffence? > > > * 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. Some filesystems will store xattrs as metadata - in exactly the same as, say, the inode itself, it's permissions, mappings etc. I'm not sure why xattrs get special treatment, compared with a hypothetical FIEMAP_FLAG_METADATA for example, indicating which physical blocks contain the inode itself, or it's other auxiliary information. (Aside: If there was a way to get physical block address for inodes (without retrieving the inodes, using only the name) I know at least one program that would benefit from that - it sorts stat() calls by estimated inode block, which greatly speeds up scanning a large filesystem. I realise FIEMAP isn't an appropriate interface for that.) > > (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). Ok. This wasn't clear, as 'direct access' means O_DIRECT elsewhere - and some programs which use FIEMAP are likely to be the same ones which use O_DIRECT. Maybe calling it 'physical addressing' or something like that? Because the field is called 'fe_physical', I'm thinking FIEMAP_EXTENT_PHYSICAL is a much clearer flag name. Also reversing the sense, so it's _set_ when 'fe_physical' is a valid quantity. (A flag FIEMAP_EXTENT_O_DIRECT to indicate when O_DIRECT access will work sounds useful too, and quite easy to implement, btw.) -- Jamie