From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: [RFC][PATCH 0/5] Fiemap, an extent mapping ioctl Date: Thu, 29 May 2008 15:41:23 -0600 Message-ID: <20080529214123.GH2985@webber.adilger.int> References: <20080525000148.GJ8325@wotan.suse.de> <20080525194203.GB24328@infradead.org> <20080527185622.GR8325@wotan.suse.de> <20080527203124.GC27827@mail.oracle.com> <20080528160201.GA7263@webber.adilger.int> <20080528170419.GA6031@mail.oracle.com> <20080529005134.GB12405@disturbed> <20080529130254.GB21299@infradead.org> <483ECCB5.5060909@hp.com> <20080529185616.GA2655@mail.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: jim owens , Christoph Hellwig , Mark Fasheh , linux-fsdevel@vger.kernel.org To: Joel Becker Return-path: Received: from sca-es-mail-2.Sun.COM ([192.18.43.133]:53501 "EHLO sca-es-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751919AbYE2Vlg (ORCPT ); Thu, 29 May 2008 17:41:36 -0400 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4TLfZft020830 for ; Thu, 29 May 2008 14:41:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1N00D01G64RV00@fe-sfbay-10.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Thu, 29 May 2008 14:41:35 -0700 (PDT) In-reply-to: <20080529185616.GA2655@mail.oracle.com> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On May 29, 2008 11:56 -0700, Joel Becker wrote: > On Thu, May 29, 2008 at 11:33:09AM -0400, jim owens wrote: > > Christoph Hellwig wrote: > >> What use is there geeting the extent count for a range? I'd rather > >> do it only per-file like the xfs ioctl. > > > > I'll answer that from practical experience. Our api equivalents: > > > > __u64 fm_start; /* logical offset (inclusive) at > > * which to start mapping (in) */ > > __u64 fm_length; /* logical length of mapping which > > * userspace cares about (in) */ > > __u32 fm_extent_count; /* size of fm_extents array (in) */ > > __u32 fm_mapped_extents; /* number of extents that were > > * mapped (out) */ > > > > ... note it has no flags field and no separate ioctl_extent_count. > > > > "fm_extent_count" is > > IN == max_extents to return. > > OUT == number of extents remaining in-range after fm_mapped_extents > > > > Pass in fm_extent_count==0 and you get OUT number of extent entries > > within your fm_start + fm_length range. Which you can use to set > > your malloc size because the FS can have massive extent counts :( > > See, that's a very natural API. I'd be much happier with that - > "extent_count == 0" is consistent with no extent structures passed in. > It also fits with many other API that do it the same way (eg, snprintf). So, to clarify, you are suggesting that FIEMAP_FLAG_NUM_EXTENTS isn't needed, and returning the extent count should just be detected by calling FIEMAP with fm_extent_count == 0? I'm OK with that also, since calling it with fm_extent_count == 0 doesn't make sense otherwise. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.