From owner-freebsd-arch Thu Oct 28 2:33:56 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 495CA14ED3 for ; Thu, 28 Oct 1999 02:33:47 -0700 (PDT) (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 LAA23052 for ; Thu, 28 Oct 1999 11:33:45 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA31990 for freebsd-arch@freebsd.org; Thu, 28 Oct 1999 11:33:45 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C0B4714F06 for ; Thu, 28 Oct 1999 02:33:26 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id CAA26105; Thu, 28 Oct 1999 02:33:22 -0700 (PDT) Date: Thu, 28 Oct 1999 02:33:22 -0700 (PDT) From: Julian Elischer To: peter.jeremy@alcatel.com.au Cc: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes In-Reply-To: <99Oct28.135145est.40328@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG These are called nanofiles. Bill Jolitz talked about them in a talk he did on BSD in '91 In effect we already do that.. note how malloc(3) uses a symlink to read its config info :-). On Thu, 28 Oct 1999, Peter Jeremy wrote: > I'd like to float the possibility of storing small (<= 60 bytes) files > and maybe directories inside inodes, in the same manner as short > symlinks are stored. > > Looking through my main system, about 12.5% of inodes are allocated > to short files and a further 3.5% are allocated to short directories. > > Advantages: > - Faster access to the file (since the inode contains the contents, > rather than a pointer to the contents). > - In my case, saving about 1.3% of disk space though this would > increase if I moved to a larger fragment size. > > Disadvantages: > - Filesystem media incompatability we'd have the code to read it turned on by default for 6 months before we turned on the default to write them. > > Programs affected (based on the programs that have special handling > for symlinks via MAXSYMLINKLEN or fs_maxsymlinklen): > - fsck(8), fsdb(8) and dump(8) > - libstand/ufs.c > > The kernel handling would be more complex than for symlinks because > files additionally have the ability to be mmap'd and updated, but I > don't believe the problems are insurmountable. > > Comments? I vaguely remember a paper on the topic. Maybe kirk can tell us more. > > Peter > -- > Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au > Alcatel Australia Limited > 41 Mandible St Phone: +61 2 9690 5019 > ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message