On Thu, Dec 19, 2002 at 10:57:15AM +1100, Luke Mewburn wrote:
  | I am investigating the performance versus complexity trade-offs
  | of converting METALOG to a btree(3) file, and using db(1) to
  | add entries that are currently manually added with "cat -l",
  | and also using db(1) to dump the info into pax.  If this works,
  | it should speed up the "maketars" and "installsets" targets in
  | distrib/sets when using UNPRIVED...

So, I took at look at this, with interesting results.

I changed install(8) to use btree(3) to write to the METALOG (indexed
on pathname)).
I changed the manual additions of entries to the metalog from using
"cat -l >> ${METALOG}" to "db -w -q -E B -R -f - btree ${METALOG}".
The "cat ${METALOG}" in distrib/sets/maketars was replaced with
"db btree ${METALOG}"
There were some other minor tweaks as well.

It *almost* worked, except for hard links files where the "real" entry
was alphabetically ordered in the db after the linked entry, so things
got confused.  (This caused chfn/chpass/chsh to lose its setuid bit,
amongst other things).  I thought of a solution to this (if metalogging
a hard link, db->get() the target from the metalog db, and use that
info instead).  However, I haven't bothered with fixing that, because ...

... I've decided to not proceed with this change, given that a recent
change I made to the existing METALOG support greatly improved the
performance of "maketars" to the point where I don't think a db is
going to help much at this point.

It was a worthwhile experiment to perform, and it would have meant
there was a use for the "db(1)" tool I wrote recently, but in the end,
I decided the extra complexity wasn't worth it.

Luke.