On Thu, 4 Dec 1997 03:54:18 +1100 (EST) 
 Darren Reed <darrenr@arbld.unimelb.edu.au> wrote:

 > > /* dia_flags */
 > > #define	DIAF_NEXT_VALID	0x00000001	/* dia_next is valid */
 > 
 > I don't think this is needed.  That field should not be controlled by
 > a user and as such, it's either going to be 0 (no next) or point to
 > something useful.  But, other flags might be useful..

I didn't say the user would control that field :-)  The user would only
supply the aux data portion, and the meta-metadata would be manipulated
only by the kernel.

I think using 0 for "end of list" would be wrong; is 0 a valid file system
block number?

 > Hmmm...I'd prefer to use inodes rather than disk blocks.  Disk blocks
 > are quite large...

Except... if you're using inodes, you're stuck with the inode structure.
I want to be able to have a list of users who can access this file... or
a database entry that describes silo/tape/file for an HSM.

An alternative could be pointing to an inode that is used only to reference
additional frags/blocks that hold the additional information.

I do see your gripe, though... "what if I only want to store an additional
16 bytes?"

One possible solution is to add a reference count to the dinode_aux,
and allow it to be referenced by more than one dinode.  Then a single
disk block could hold multiple entries (managed by whatever subsystem
wants the extra metadata, indexed by whatever method it chooses).

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-6                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939