Subject: Re: `Large Inodes'
To: Chris G. Demetriou <email@example.com>
From: Stefan Grefen <firstname.lastname@example.org>
Date: 03/30/1999 12:43:11
In message <email@example.com> Chris G. Demetriou wrote:
> Jason Thorpe <firstname.lastname@example.org> writes:
> > On Fri, 26 Mar 1999 09:03:36 -0500 (EST)
> > "Charles M. Hannum" <email@example.com> 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.
> Chris Demetriou - firstname.lastname@example.org - http://www.netbsd.org/People/Pages/cgd.html
> Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
Stefan Grefen Tandem Computers Europe Inc.
email@example.com High Performance Research Center
--- Hacking's just another word for nothing left to kludge. ---