Subject: Re: `Large Inodes'
To: Jason Thorpe <email@example.com>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 03/26/1999 11:01:56
Jason Thorpe <email@example.com> writes:
> On Fri, 26 Mar 1999 09:03:36 -0500 (EST)
> "Charles M. Hannum" <firstname.lastname@example.org> 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
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?!"
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 - email@example.com - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.