From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Sandeen Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Thu, 26 Jun 2008 09:03:49 -0500 Message-ID: <4863A1C5.7020403@redhat.com> References: <20080625221835.GQ28100@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Josef Bacik To: Mark Fasheh Return-path: Received: from mx1.redhat.com ([66.187.233.31]:57562 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752948AbYFZOEB (ORCPT ); Thu, 26 Jun 2008 10:04:01 -0400 In-Reply-To: <20080625221835.GQ28100@wotan.suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Mark Fasheh wrote: > Hello, > > The following patches are the latest attempt at implementing a > fiemap ioctl, which can be used by userspace software to get extent > information for an inode in an efficient manner. > > These patches are against 2.6.26-rc3, though they probably apply > fine against Linus' latest tree. The fs patches are much more complete this > time around, and the vfs patch has been trimmed down. > > An updated version of my ioctl wrapper test program is available at: > > http://www.kernel.org/pub/linux/kernel/people/mfasheh/fiemap/tests/ > > A couple of notes regarding the VFS patch: > > Firstly, most behavior-changing fm_flags have been removed. We're > left with SYNC and XATTR now. This is a very good thing because frankly, I > think fiemap should be targeted as a straight-forward and relatively > uncomplicated API for exposing extents as they appear on disk. Think "one > notch above extent-based FIBMAP replacement". So Mark's gonna hate me for this 'cause I was acting all resigned last night, but I have to throw this out (sorry Mark!) Right now the interface seems to be about returning details of the filesystem's accounting of the on-disk layout, as opposed to just a simple mapping. As 2 examples: 1) If you have 8 contiguous 128M extents for a 1G file, currently the interface will (or may) give you back 8 extents for the entire file, even though the file is 100% unfragmented, because that reflects the details of the filesystem's internal accounting. 2) Further, if you ask for a mapping of that file between 100M and 200M (logical), you will (or may) get back 2 extents between 0M and 256M because again, that is how the filesystem is tracking the layout internally. (compare with a simple mapping-only interface which would return a single range from 0 to 1G, or from 100M to 200M). Either approach has its merits, depending on what you want the interface to do I suppose. Maybe it should even be (gasp) another flag to switch between one or the other? (merge & trim extents vs. distinct & full extents?) For filesystem debugging work I see the value in returning some details of the filesystem's internal representation of the layout. For a mapping interface, I think it complicates things for the caller. In the end I can live with either as long as we're explicit about it, but I think it's worth pointing out. -Eric