In message <87677o13dn.fsf@redmail.redback.com>  Chris G. Demetriou wrote:
> Jason Thorpe <thorpej@nas.nasa.gov> writes:
> > On Fri, 26 Mar 1999 09:03:36 -0500 (EST) 
> >  "Charles M. Hannum" <root@ihack.net> 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 - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
> Disclaimer: Not speaking for NetBSD, just expressing my own opinion.

Stefan

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