From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: [RFC][PATCH 0/5] Fiemap, an extent mapping ioctl Date: Tue, 27 May 2008 09:48:51 -0400 Message-ID: <200805270948.51898.chris.mason@oracle.com> References: <20080525000148.GJ8325@wotan.suse.de> <20080525194203.GB24328@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Eric Sandeen , Josef Bacik To: Christoph Hellwig Return-path: Received: from agminet01.oracle.com ([141.146.126.228]:64485 "EHLO agminet01.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755567AbYE0Nv0 (ORCPT ); Tue, 27 May 2008 09:51:26 -0400 In-Reply-To: <20080525194203.GB24328@infradead.org> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sunday 25 May 2008, Christoph Hellwig wrote: Thanks for doing this Mark ;) > On Sat, May 24, 2008 at 05:01:48PM -0700, Mark Fasheh wrote: > > * FIEMAP_FLAG_HSM_READ > > If the extent is offline, retrieve it before mapping and do not flag > > it as FIEMAP_EXTENT_SECONDARY. This flag has no effect if the file > > system does not support HSM. > > Given that there's no HSM support in mainline this should not be added. > It'll be useful once we add proper HSM support, though :) > The HSM flag doesn't hurt, and it allows the people actually shipping hsm patches to use fiemap without extending the api themselves. Reserving the flag isn't a bad idea. > > * FIEMAP_FLAG_LUN_ORDER > > If the file system stripes file data, this will return contiguous > > regions of physical allocation, sorted by LUN. Logical offsets may not > > make sense if this flag is passed. If the file system does not support > > multiple LUNs, this flag will be ignored. > > A LUN doesn't make any sense in filesystem context. That's a > scsi-centric acronym that doesn't even make sense in a scsi-centric > filesystem universe because a LUN can of course contain multiple > partitions. It's also extremly ill-defined when using volume managers. > > There's also no filesystems that actually support a single file on > multiple device in mainline, the only filesystem that supports multiple > data devices at all (XFS) requires each file to be on a single device. > > Once we have a filesystem with real multiple data device support like > btrfs or a future XFS version we can worry about this and defined > a different ioctl for it. > For btrfs I would return the logical extents via fiemap (just like the file were on lvm) and make btrfs specific ioctls for details about where the file actually lived. fiemap alone isn't a great way to describe raid levels or complex storage topologies. To include physical information I would also have to encode the raid level used and information about all the devices the data is replicated on (raid1/10) -chris