Subject: Re: `Large Inodes'
To: Chris G. Demetriou <>
From: Stefan Grefen <>
List: tech-kern
Date: 03/30/1999 12:43:11
In message <>  Chris G. Demetriou wrote:
> Jason Thorpe <> writes:
> > On Fri, 26 Mar 1999 09:03:36 -0500 (EST) 
> >  "Charles M. Hannum" <> wrote:
> >  > Furthermore, if I understand the problem you're actually trying to
> >  > solve, I think the `large inode' solution is an exceptionally poor way
> >  > to solve it.  If you're stacking something on top of FFS, there's no
> >  > reason the stacked layer can't keep its data elsewhere.  This is,
> >  > actually, the whole *point* of stacked VFS layers.  This data simply
> >  > doesn't belong in FFS at all.
> > 
> > ...the issue with keeping it elsewhere is, quite simply, performance
> > concerns.
> Have you demonstrated a performance problem with trying to keep it
> elsewhere?  (I mean, has your team which is doing the work tried it
> other ways, e.g. keeping a separate "ifile"-like entity for example,
> and shown that they result in unreasonable performance?)
> "If not, why are you optimizing it?!"

An additional directory lookup (looking for that inode in a database),
is costly. It wouldn't hurt nasstor too bad, as it's only interested in
this stuff if the file is not-there (AFAIK) or on a ls -l.
But this is what Charles calles the berkeley solution. ACL may be
checked for every read/write call (and its easier to cache them
them if they are stored in a same inode).

> Naively, in thinking about the problems inherent in handling large
> data sets/files and data migration to/from tape, i'd think that an
> extra local file lookup ... would not be your performance bottleneck.
> 8-)
> cgd
> -- 
> Chris Demetriou - -
> Disclaimer: Not speaking for NetBSD, just expressing my own opinion.


Stefan Grefen                                Tandem Computers Europe Inc.                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---