From mboxrd@z Thu Jan 1 00:00:00 1970 From: jim owens Subject: Re: [PATCH 1/4] vfs: vfs-level fiemap interface Date: Mon, 06 Oct 2008 14:15:08 -0400 Message-ID: <48EA55AC.2060102@hp.com> References: <1223071147-27180-1-git-send-email-tytso@mit.edu> <1223071147-27180-2-git-send-email-tytso@mit.edu> <20081004021251.GA29174@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, Mark Fasheh , Michael Kerrisk , linux-abi@vger.kernel.org To: Theodore Tso Return-path: Received: from g4t0016.houston.hp.com ([15.201.24.19]:24993 "EHLO g4t0016.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751633AbYJFSPM (ORCPT ); Mon, 6 Oct 2008 14:15:12 -0400 In-Reply-To: <20081004021251.GA29174@mit.edu> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: A couple of old documentation nits that were to be fixed: > +fm_extents[] to hold the file's current mapping. Note that there is > +nothing to prevent the file from changing between calls to FIEMAP. > + > +Currently, there are three flags which can be set in fm_flags: Current flags which can be set in fm_flags: > + > +* FIEMAP_FLAG_SYNC > +If this flag is set, the kernel will sync the file before mapping extents. > + > +* 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. extended attributes, otherwise the extents describe the file data. ----------------------------------------------- And a documentation issue with this new change: > + > +* FIEMAP_EXTENT_NO_MOUNTED_IO Did you really intend to name it FIEMAP_EXTENT_NO_MOUNTED_IO or did you intend it to be FIEMAP_EXTENT_NO_UNMOUNTED_IO ? > +Accessing the data in this extent via I/O to the block device while the > +filesystem is unmounted is illegal or will have undefined results. This > +may because the data is somehow encrypted or compressed by the filesystem. may be because the data is somehow encrypted or compressed by the filesystem. > +Note that accessing the data using the information returned by the > +FIEMAP interface is *always* undefined should not be attempted by user > +applications. FIEMAP interface is never guaranteed to be consistent and should not be attempted by user applications. [ IMO - it is confusing to say "undefined" when the flag is ] [ set and also say "undefined" when the flag is clear ] jim