From owner-freebsd-arch Mon Nov 1 7:34:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EBACD14FD8 for ; Mon, 1 Nov 1999 07:34:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA03565 for ; Mon, 1 Nov 1999 16:34:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA73218 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 16:34:42 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 421F3151C8 for ; Mon, 1 Nov 1999 07:34:32 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id KAA23101 for ; Mon, 1 Nov 1999 10:29:48 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes References: <99Oct29.085056est.40332@border.alcanet.com.au> <19991029150228.BB45314BF7@hub.freebsd.org> <99Nov1.100916est.40382@border.alcanet.com.au> From: Randell Jesup Date: 01 Nov 1999 11:30:58 +0000 In-Reply-To: Peter Jeremy's message of "Mon, 1 Nov 1999 10:13:35 +1100" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Jeremy writes: >>http://www.usenix.org/publications/library/proceedings/ana97/ganger.html >> >>With embedded inodes, the inodes for most files are stored in the >>directory with the corresponding name, removing a physical level of >>indirection without sacrificing the logical level of indirection. With >>explicit grouping, the data blocks of multiple small files named by a >>given directory are allocated adjacently and moved to and from the >>disk as a unit in most cases. > >C-FFS is a more radical change than I was thinking of. By moving the >inodes into the directory, it needs special handling for files don't >have exactly 1 link. True, though this is similar (in complexity) to the special handling for small files inside inodes - probably simpler, given issues of mmap/etc for the later. >Also, from my reading of the paper, a small >file still occupies a complete data block, it's just that the data >block is `close to' the directory entry/inode for the file. True. However, saving the extra level of indirection and the improved match to the physical characteristics of modern drives is a major win. The tendency is that the small file block will be in the cache anyways, or at worst within the drive's cache. You could preferentially put smaller files closer to the directory nodes. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message