From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Wed, 02 Jul 2008 00:38:29 -0600 Message-ID: <20080702063829.GR6239@webber.adilger.int> References: <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> <20080630225730.GC20187@shareable.org> <20080630230741.GE28100@wotan.suse.de> <20080701020103.GA22868@cynthia.pants.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: Mark Fasheh , Jamie Lokier , Anton Altaparmakov , Eric Sandeen , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Josef Bacik To: Brad Boyer Return-path: Received: from sca-es-mail-1.Sun.COM ([192.18.43.132]:63772 "EHLO sca-es-mail-1.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755546AbYGBGic (ORCPT ); Wed, 2 Jul 2008 02:38:32 -0400 Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m626cVvE025484 for ; Tue, 1 Jul 2008 23:38:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3D000018YELY00@fe-sfbay-09.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Tue, 01 Jul 2008 23:38:31 -0700 (PDT) In-reply-to: <20080701020103.GA22868@cynthia.pants.nu> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jun 30, 2008 19:01 -0700, Brad Boyer wrote: > What would you expect as reasonable behavior for an FS type that > doesn't have distinct storage for directories? On HFS and HFS+, the > directory information is completely synthetic based on the parent > ID of each file. A directory has no actual data dedicated to it > other than the basic metadata that would be in the inode in ext3, > and readdir just walks the catalog tree and finds all the entries > that say they have the directory you want as a parent. They are > sorted that way, so it's not as bad as it sounds for performance. > > Would it be reasonable for a filesystem like this to just say that > a directory has no extents at all? You can open a directory and > seek to an offset, but that doesn't logically map to any place > on the disk. Is this going to cause problems? Even though the directory data isn't stored in a separate "file", the inodes that make up the "directory" still consume space on disk. If I were writing a FIEMAP handler for such a filesystem, I'd probably return the byte range of the "catalog tree" that match the directory "parent". Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.