From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Fasheh Subject: Re: [RFC][PATCH 0/5] Fiemap, an extent mapping ioctl Date: Tue, 27 May 2008 14:10:05 -0700 Message-ID: <20080527211005.GU8325@wotan.suse.de> References: <20080525000148.GJ8325@wotan.suse.de> <20080525194203.GB24328@infradead.org> <20080526105944.GN3516@webber.adilger.int> <20080527164546.GA9707@infradead.org> Reply-To: Mark Fasheh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andreas Dilger , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Eric Sandeen , Josef Bacik To: Christoph Hellwig Return-path: Received: from mx2.suse.de ([195.135.220.15]:59952 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756474AbYE0VKG (ORCPT ); Tue, 27 May 2008 17:10:06 -0400 Content-Disposition: inline In-Reply-To: <20080527164546.GA9707@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, May 27, 2008 at 12:45:46PM -0400, Christoph Hellwig wrote: > > I don't see why we need a different ioctl for mapping extents on a > > filesystem that support direct access to multiple disks. Having one > > mechanism that returns the file mapping is much more simple for user > > space applications (filefrag, cp, tar, gzip, etc) than having to use > > different ioctls for different backing filesystems. > > Well, we could add a dev field that contains the dev_t for the > underlying block device. That would work for the current XFS realtime > device aswell as for my work to map different XFS AGs to different > devices. It wouldn't work for btrfs with integrated raid code where > a single extent can span multiple underlying devices, the same probably > applies to pnfs. Dev_t seems reasonable to me. Anything any more complicated than just wanting a simple device identifier needs a more dedicated API. --Mark -- Mark Fasheh