From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Tso Subject: Re: [PATCH 1/4] vfs: vfs-level fiemap interface Date: Mon, 6 Oct 2008 17:07:06 -0400 Message-ID: <20081006210706.GB8139@mit.edu> References: <1223071147-27180-1-git-send-email-tytso@mit.edu> <1223071147-27180-2-git-send-email-tytso@mit.edu> <20081004021251.GA29174@mit.edu> <48EA55AC.2060102@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, Mark Fasheh , Michael Kerrisk , linux-abi@vger.kernel.org To: jim owens Return-path: Received: from www.church-of-our-saviour.ORG ([69.25.196.31]:40855 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752173AbYJFVHL (ORCPT ); Mon, 6 Oct 2008 17:07:11 -0400 Content-Disposition: inline In-Reply-To: <48EA55AC.2060102@hp.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Oct 06, 2008 at 02:15:08PM -0400, jim owens wrote: >> + >> +Currently, there are three flags which can be set in fm_flags: > > Current flags which can be set in fm_flags: > Good catch, thanks. > 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 ? The latter; thanks for catching that > 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 ] > Yeah. Is this better? +* 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 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 while the filesystem is mounted is *always* undefined +should not be attempted by user applications. - Ted