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 11:17:08 -0600 Message-ID: <20080626171708.GS6239@webber.adilger.int> References: <20080625221835.GQ28100@wotan.suse.de> <20080626093634.GA30025@shareable.org> <20080626102403.GN6239@webber.adilger.int> <20080626121950.GB32417@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]:52048 "EHLO sca-es-mail-1.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760078AbYFZSBi (ORCPT ); Thu, 26 Jun 2008 14:01:38 -0400 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5QHHG1F022574 for ; Thu, 26 Jun 2008 10:17:16 -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 <0K3200D01XO40C00@fe-sfbay-10.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Thu, 26 Jun 2008 10:17:16 -0700 (PDT) In-reply-to: <20080626121950.GB32417@shareable.org> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jun 26, 2008 13:19 +0100, Jamie Lokier wrote: > Andreas Dilger wrote: > > "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. Well, in most cases the physical addresses are valid (except if FIEMAP_EXTENT_NET), but the point of NO_DIRECT is that if some application were to read the data directly from disk (e.g. lilo, or dump) it won't necessarily get the data it expects. I agree the name is a bit confusing, and maybe a clarification should be made w.r.t. the fact it has nothing to do with O_DIRECT, but I can't think of a better name for it. The NO_DIRECT flag will normally have another qualifier that explains why it isn't directly accessible, but apps which don't care WHY it isn't accessible don't need to check for each of those flags. > (A flag FIEMAP_EXTENT_O_DIRECT to indicate when O_DIRECT access will > work sounds useful too, and quite easy to implement, btw.) There is already the FIEMAP_EXTENT_NOT_ALIGNED flag, which is the opposite of what you ask for - it marks extents that are not properly aligned to block boundaries: * FIEMAP_EXTENT_NOT_ALIGNED Extent offsets and length are not guaranteed to be block aligned. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.