Subject: Re: more on dinode
To: Matthew Jacob <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 12/03/1997 11:56:32
On Tue, 2 Dec 1997 11:45:14 -0800 Matthew Jacob wrote:
> From email@example.com Tue Dec 2 11:44:17 1997
> Date: Tue, 2 Dec 1997 11:41:18 -0800 (PST)
> From: Alan Poston <firstname.lastname@example.org>
> To: Matthew Jacob <email@example.com>
> cc: firstname.lastname@example.org
> 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: email@example.com
> > >Delivered-To: firstname.lastname@example.org
> > >From: Darren Reed <email@example.com>
> > >Subject: dinode: di_spare
> > >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 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_.
ps: should this have stayed internal and not migrated to tech-kern?
Or the other way around?