>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.

-Alan

 > >
> >For example, it might be a reference to an ACL (or a file to be used as
> >an ACL) or it might be a pointer to an inode which is the executeable to
> >run with that file (i.e. /etc/passwd would have a reference to (say) vipw
> >and if you ran /etc/passwd, vipw would run).  The latter of these examples
> >is probably something most of us would puke on, given that it is perhaps
> >more of a Windows/Macintosh feature, but it's something I see winning
> >favour with "users".  Also, combinations would be allowed through linking
> >of "extended information inode".
> >
> >I should point out I'm not trying to define further uses for "extended
> >infromation inodes" (yet :-), just some possibilities of what I see as
> >relevant uses.  This idea is really just to open up the possibilities
> >for future development and enhancements before someone does something
> >silly with those last 64 bits :-)
> >
> >Oh, and for maximum benefit, yes, dump/restore would need to be tought
> >about them, as well as tar and cpio.  It would be good if the other
> >4.4-BSD based groups picked up on the skeleton idea (I hope the vague
> >acceptance of it as an extension is better able to get support than an
> >actual purpose or implementation), but that cannot be counted upon.
> >
> >Darren
> >
>