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: Fri, 04 Jul 2008 03:00:57 -0600 Message-ID: <20080704090057.GQ6239@webber.adilger.int> References: <20080625221835.GQ28100@wotan.suse.de> <486CE430.9010902@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: linux-fsdevel@vger.kernel.org, mfasheh@suse.com To: jim owens Return-path: Received: from sca-es-mail-1.Sun.COM ([192.18.43.132]:39739 "EHLO sca-es-mail-1.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753036AbYGDJBA (ORCPT ); Fri, 4 Jul 2008 05:01:00 -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 m6490xZg002608 for ; Fri, 4 Jul 2008 02:00:59 -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 <0K3H00K0150UZW00@fe-sfbay-09.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Fri, 04 Jul 2008 02:00:59 -0700 (PDT) In-reply-to: <486CE430.9010902@hp.com> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jul 03, 2008 10:37 -0400, jim owens wrote: >> * FIEMAP_EXTENT_NO_DIRECT >> Direct access to the data in this extent is illegal or will have >> undefined results. > > will confuse and mislead many people. And as Andreas said, > the fe_physical and fe_device can be valid without the ability > to directly access the data. I suggest we call this: > > FIEMAP_EXTENT_NO_BYPASS > > As in "you can't bypass the filesystem" to directly access it. > > Based on what Andreas said the NO_DIRECT (NO_BYPASS) means, > I disagree with these: > >> * FIEMAP_EXTENT_NET >> - This will also set FIEMAP_EXTENT_NO_DIRECT >> The data for this extent is not stored in a locally-accessible device. >> >> * FIEMAP_EXTENT_DATA_COMPRESSED >> - This will also set FIEMAP_EXTENT_NO_DIRECT >> The data in this extent has been compressed by the file system. >> >> * FIEMAP_EXTENT_DATA_ENCRYPTED >> - This will also set FIEMAP_EXTENT_NO_DIRECT >> The data in this extent has been encrypted by the file system. > > None of the above are always NO_DIRECT. Certainly you can > read the raw compressed/encrypted data (a backup program might) > and even a netdev might be accessed if you know how. I don't see that calling this "NO_BYPASS" is significantly different than calling it "NO_DIRECT". You can "bypass" that flag just as easily, the point is that you may get garbage out of it, don't do that. I don't think anyone writing an application will be seriously confused. >> * FIEMAP_EXTENT_NOT_ALIGNED >> Extent offsets and length are not guaranteed to be block aligned. > > To be something like: > > FIEMAP_EXTENT_ENCODED That doesn't make sense either. "NOT_ALIGNED" just means that it isn't a full filesystem block, but it isn't necessarily "encoded" in any way. >> * FIEMAP_EXTENT_DATA_INLINE >> This will also set FIEMAP_EXTENT_NOT_ALIGNED >> Data is located within a meta data block. >> >> * FIEMAP_EXTENT_DATA_TAIL >> This will also set FIEMAP_EXTENT_NOT_ALIGNED >> Data is packed into a block with data from other files. > > With FIEMAP_EXTENT_ENCODED being the top flag set for > FIEMAP_EXTENT_NET, FIEMAP_EXTENT_DATA_COMPRESSED, > FIEMAP_EXTENT_DATA_ENCRYPTED, FIEMAP_EXTENT_DATA_INLINE, > and FIEMAP_EXTENT_DATA_TAIL. Then FIEMAP_EXTENT_NO_BYPASS > may or may not also be set and would say "can I get to > the physical data", and separately "do I need to do > special processing on it" would be FIEMAP_EXTENT_ENCODED. It seems to me that "ENCODED" has no relation to "NET" or "DATA_TAIL" or "DATA_INLINE". >> * FIEMAP_EXTENT_UNWRITTEN >> Unwritten extent - the extent is allocated but it's data has not been >> initialized. This indicates the extent's data will be all zero. > > This should say "will be all zero if read through the filesystem > but the contents are undefined if read directly." That does make sense and should be updated. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.