From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2
Date: Thu, 26 Jun 2008 10:36:35 +0100
Message-ID: <20080626093634.GA30025@shareable.org>
References: <20080625221835.GQ28100@wotan.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org, Andreas Dilger <adilger@shaw.ca>,
	Kalpak Shah <Kalpak.Shah@sun.com>,
	Eric Sandeen <sandeen@redhat.com>,
	Josef Bacik <jbacik@redhat.com>
To: Mark Fasheh <mfasheh@suse.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail2.shareable.org ([80.68.89.115]:46187 "EHLO
	mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754760AbYFZJgh (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 26 Jun 2008 05:36:37 -0400
Content-Disposition: inline
In-Reply-To: <20080625221835.GQ28100@wotan.suse.de>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

Mark Fasheh wrote:
> * FIEMAP_FLAG_SYNC
> If this flag is set, the kernel will sync the file before mapping extents.

Is there a reason why fsync() before calling FIEMAP is unsuitable?

> * 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.

What is this for?  The meaning of the xattr tree sounds rather
filesystem specific to me.

> * FIEMAP_EXTENT_NO_DIRECT
> Direct access to the data in this extent is illegal or will have
> undefined results.
...
> * FIEMAP_EXTENT_NET
>   - This will also set FIEMAP_EXTENT_NO_DIRECT
> The data for this extent is not stored in a locally-accessible device.

Does this _always_ set FIEMAP_EXTENT_NO_DIRECT?  Some network
filesystems do support O_DIRECT access - NFS comes to mind.

(I'm assuming 'direct access' means O_DIRECT).

> * FIEMAP_EXTENT_DATA_ENCRYPTED
>   - This will also set FIEMAP_EXTENT_NO_DIRECT
> The data in this extent has been encrypted by the file system.

I don't think encryption necessarily rules out O_DIRECT.  It'll depend
how I/O is implemented by that filesystem.

> * FIEMAP_EXTENT_DATA_INLINE
>   This will also set FIEMAP_EXTENT_NOT_ALIGNED
> Data is located within a meta data block.

This seems like it would always set FIEMAP_EXTENT_NO_DIRECT :-)

(Generally, won't FIEMAP_EXTENT_NOT_ALIGNED always set
FIEMAP_EXTENT_NO_DIRECT?)

> * FIEMAP_EXTENT_DATA_TAIL
>   This will also set FIEMAP_EXTENT_NOT_ALIGNED
> Data is packed into a block with data from other files.

Maybe this too.

-- Jamie