[Tux3] A new file! ileaf.c

[Daniel Phillips]

Some inode table leaf methods have landed.

   http://tux3.org/tux3?f=0f978a4556b3;file=user/test/ileaf.c

Similar to a file index leaf, an inode table leaf contains some number
of inodes at the base and a dictionary stored upside down at the top of
the block.  The dictionary in this case is much simpler than the two
level design used in fleaf.c, and is just a vector of limit offsets in
the leaf, showing where each inode ends and the next begins.  Like the
fleaf index, limits of inodes are stored rather than base offsets so
that instead of the first entry always being zero, the last entry gives
the beginning of free space in the leaf.

Any inode of zero size (two successive identical limits) is unused.
There is an inode_expand operation that adds more space to the end of
an inode to store additional (versioned) attributes.  There is no actual
attribute code implemented yet (similarly, the versioned pointer
operations have not yet been integrated with fleaf.c) so for now the
expand just fills the new space with some byte value to make it easy to
see if the inode contents are properly preserved by the various
operations.

Each inode table leaf contains a "clump" of inodes starting at
leaf->inum and continuing to the last active inode in the clump.
The dictionary represents unused inodes between active inodes, but
unused inodes trailing the last active inode are supposed to be trimmed
whenever possible (which is not always done in the current code).  I
am not sure whether it also makes sense to trim unused inodes from the
beginning of a clump, as this costs a memory move and the base inode
of the leaf would then not match the btree index value.  Would anything
be gained by trimming those?  Ponder.

Question: should inode table entries by aligned on 4 or 8 bytes, or
should they be unaligned, giving somewhat better packing when odd
sized attributes such as immediate file data are present but costing
more cpu cycles to access unaligned numeric fields, especially on cpu
architectures without native support for unaligned field access, such
as SPARC (and ARM?).

Inode table leaf operations implemented are:

   ileaf_create
   ileaf_destroy
   ileaf_used
   ileaf_free
   ileaf_dump
   ileaf_check
   ileaf_split
   ileaf_merge

Inode editing operations implemented are:

   inode_lookup
   inode_expand

The inode_expand operation turns an unused inode into an active inode,
or makes more space in an existing inode.  There may also need to be an
inode_shrink, although that might turn out to be handled entirely by
inode version delete.

Like the file leaf methods, version delete is not yet implemented, or
completely designed.  Getting close.

Like the file leaf methods, ileaf.c is a stand-alone test program that
runs operations of various kinds and show the results.  "This is call
for testing".

Regards,

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3