On Tue, 2 Dec 1997 11:45:14 -0800  Matthew Jacob wrote:
> 
> From owner-storage-devel@nas.nasa.gov  Tue Dec  2 11:44:17 1997
> Date: Tue, 2 Dec 1997 11:41:18 -0800 (PST)
> From: Alan Poston <poston@nas.nasa.gov>
> To: Matthew Jacob <mjacob@ns.feral.com>
> cc: storage-devel@nas.nasa.gov
> Subject: Re: RASH on NetBSD- someone ought to respond...
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> On Sun, 30 Nov 1997, Matthew Jacob wrote:
> 
> > >From netbsd-internal-owner-mjacob=netbsd.org@NetBSD.ORG  Sun Nov 30 22:50:11 1997
> > >Delivered-To: mjacob@netbsd.org
> > >Delivered-To: netbsd-internal@netbsd.org
> > >From: Darren Reed <darrenr@cyber.com.au>
> > >Subject: dinode: di_spare[2]
> > >To: netbsd-internal@NetBSD.ORG
> > >Date: Mon, 1 Dec 1997 17:49:17 +1100 (EST)
> > >X-Mailer: ELM [version 2.4 PL23]
> > >Content-Type: text
> > >Sender: netbsd-internal-owner@NetBSD.ORG
> > >Delivered-To: netbsd-internal@NetBSD.ORG
> > >
> > >
> > >I imagine there is quite a bit of hestitation about doing anything with
> > >di_spare[2] in the dinode structure which I can appreciate.  There are
> > >lots of single uses for which those bytes would be _real_ handy.  Since
> > >inodes are still 32bits (and I presume will be that way for quite some
> > >time), I'd like to propose that those last 64 bits be used for support
> > >of "extended information inodes".  That is 32 bits for another inode
> > >and the other 32 bits be used to qualify what that inode is and that the
> > >first 64 bits of the `inode' such referenced is also used in the same
> > >way.
> 
> An implementation of DMIG file system will require us to either A) use
> a simple bit in the inode to allow to kernel to ask a deamon process about
> attribute data for that inode (the so-called single bit implementation) or
> B) place the attribute data directly in the inode (or associated kernel
> database) which will require a lot more room than a couple of 32 bit fields.
> 
> I vote for a new inode structure which allows for many things to be kept
> directly in the inode... disk space is not a problem that it once was 
> (conserve every byte was the byword) so spending up to 8K or more per
> inode is not a big problem.  I'm typing up my proposal for this now, but
> expect it to have large inodes with attribute data and, possibly, file
> data (file header) contained in the inode.

8k per inode?  I've got a 2GB filesystem here with over 100k inodes and
1.5G used.  This proposal would chew up around 800MB, or about 40% of
the available space.  Disk space _isn't_ that cheap.

Maybe if a finite amount of data was kept in the inode too this wouldn't
be as bad.  Something "simpler" might be to just allocate another
fragment and use that for "funny" data _if needed_.

Simon.

ps: should this have stayed internal and not migrated to tech-kern?
Or the other way around?