From mboxrd@z Thu Jan 1 00:00:00 1970 From: jim owens Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Thu, 03 Jul 2008 10:37:36 -0400 Message-ID: <486CE430.9010902@hp.com> References: <20080625221835.GQ28100@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To: linux-fsdevel@vger.kernel.org, mfasheh@suse.com Return-path: Received: from g1t0027.austin.hp.com ([15.216.28.34]:25482 "EHLO g1t0027.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752162AbYGCOiG (ORCPT ); Thu, 3 Jul 2008 10:38:06 -0400 In-Reply-To: <20080625221835.GQ28100@wotan.suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: As Jamie pointed out, this: > * 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_SECONDARY > The data for this extent is in secondary storage (e.g. HSM). If the > data is not also in the filesystem, then FIEMAP_EXTENT_NO_DIRECT > should also be set. First, "If the data is not also in the filesystem" has no relevance. You are either providing the fe_physical and fe_device for the HSM which may or may not allow direct access, or you are providing the location in the filesystem of the primary copy in which case you are not setting FIEMAP_EXTENT_SECONDARY. I don't think you want to return BOTH the fiemap_extent primary and secondary as this will confuse the hell out of everyone. Or, as was said before, maybe HSM should wait until we know what it really needs. > * 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 think you need a different top-level flag that covers "things which are not raw block data" so I would change this: > * FIEMAP_EXTENT_NOT_ALIGNED > Extent offsets and length are not guaranteed to be block aligned. To be something like: FIEMAP_EXTENT_ENCODED > * 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. > * 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." jim