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 08:48:27 -0500 Message-ID: <48639E2B.4000401@redhat.com> References: <20080625221835.GQ28100@wotan.suse.de> <20080626093634.GA30025@shareable.org> <20080626102403.GN6239@webber.adilger.int> <20080626121950.GB32417@shareable.org> <20080626131600.GS29319@disturbed> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: Jamie Lokier , Andreas Dilger , Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah Received: from mx1.redhat.com ([66.187.233.31]:60432 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751590AbYFZNsg (ORCPT ); Thu, 26 Jun 2008 09:48:36 -0400 In-Reply-To: <20080626131600.GS29319@disturbed> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Dave Chinner wrote: > On Thu, Jun 26, 2008 at 01:19:51PM +0100, Jamie Lokier wrote: >> Andreas Dilger wrote: >>>> Is there a reason why fsync() before calling FIEMAP is unsuitable? >>> This was added because the xfsbmap operation always did an fsync before >>> returning the extents. I don't think it is strictly required, but it >>> isn't harmful either. >> It's not harmful but suggests it might do something important - >> e.g. provide atomicity between the fsync and getting extends. > > It does precisely that. xfs does via the bmap ioctl, but the generic fiemap implementation does not. It probably should be removed from the vfs level: + if (fieinfo.fi_flags & FIEMAP_FLAG_SYNC) + filemap_write_and_wait(inode->i_mapping); and let the filesystem handle it in an atomic way? >>>>> * 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. >>> This is to return the location of the xattr blocks for the inode. >> Some filesystems will store xattrs as metadata - in exactly the same >> as, say, the inode itself, it's permissions, mappings etc. >> >> I'm not sure why xattrs get special treatment, compared with a >> hypothetical FIEMAP_FLAG_METADATA for example, indicating which >> physical blocks contain the inode itself, or it's other auxiliary >> information. > > Because xattrs tend to contain user data, not metadata? Agreed, I don't see anything particularly strange about returning the xattr mapping, and to me it's not particularly fs specific (well, the detailed format of the on-disk data might be, i.e. the layout of names & values within that blob of data, but it is still user data... I guess it's something of a grey area). -Eric