From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Mon, 30 Jun 2008 23:57:31 +0100 Message-ID: <20080630225730.GC20187@shareable.org> References: <20080625221835.GQ28100@wotan.suse.de> <20080626093634.GA30025@shareable.org> <20080626102403.GN6239@webber.adilger.int> <20080626121950.GB32417@shareable.org> <20080626131600.GS29319@disturbed> <48639E2B.4000401@redhat.com> <20080626141649.GD3356@shareable.org> <20080626165618.GP6239@webber.adilger.int> <1DAFD0EF-FF4A-456C-A7E6-E718031E220D@cam.ac.uk> <20080629214525.GI29319@disturbed> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Anton Altaparmakov , Andreas Dilger , Eric Sandeen , Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilg Return-path: Received: from mail2.shareable.org ([80.68.89.115]:38511 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762391AbYF3W5e (ORCPT ); Mon, 30 Jun 2008 18:57:34 -0400 Content-Disposition: inline In-Reply-To: <20080629214525.GI29319@disturbed> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Dave Chinner wrote: > If you know the offset and length of the xattr, then you can get it > specifically, bu to do that you need to know about the internals of > the filesystem.... > > FWIW, this is exactly the same case as getting the extent map of a > directory data (I use xfs_bmap all the time for this) - you know > where the blocks are, but without completely decoding the directory > structure you have no idea where inside that map a given entry is. There's a thought. What does "offset" mean for directory data and FIEMAP? (And xattrs, but let's ignore that, it's less important). What's the appropriate thing to return for FIEMAP on a directory, on a filesystem which doesn't store directories as a blob of data with contiguous offsets? E.g. directory offsets (readdir) do mean something, but there's no guarantee that directory offsets 0..N-1 corresponds with extents covering N bytes exactly. Would it return extent data similar to a file with large holes? -- Jamie