I hate makedbz.

[Ron Jarrell]

At 03:34 PM 7/27/01 -0400, Ron Jarrell wrote:

>At 03:11 PM 7/27/01 -0400, Ron Jarrell wrote:
>>solaris{root}122% cat history.dir
>>dbz 6 750000 14 66
>>12791549 0 0 0 0 0 0 0 0 0 0
>>
>>Now I did the makedbz, as I said, with a -s 20000000.  Given that the 
>>history file is only 12793609, shouldn't that have been *plenty*?
>
>
>When in doubt, read the code...  If I'm understanding dbz.c right, it sounds like
>for some reason makedbz completely failed to understand the 20000000 on -s,
>and the actual size I'm using is 750000, which is the default size?  And that,
>despite the memory showing over 12mil, it elected to use 750000 again?

Ok, I tried a test... Copied the current history file set to a foo.* set.

Tried several alternatives.. Edited foo.dir to change the 750000 to 20000000
before running a makedbz -f foo.  It set it back to 750K.  Did a makedbz -f foo -s 20000000.
Same thing.  Did id -s20000000 in case there's a getopt bug.  Nope.

At least resorted to brute force.  Edited dbz.c in the library to change
#defne DEFSIZE 750000
to 
#define DEFSIZE 20000000

Which worked like a charm.  Suddenly just a makedbz -f foo generated me
a set of foo.n.* files in a little under two minutes.

So people having the multi-day expire, and the multi-day makedbz probably 
want to make a similar change until we figure out why on some systems it's
apparently ignore the size hints entirely.  I'll look at the code some more, but
it *is* nearly 5pm on a friday where I've already put in 80hours, and I have
to come in all day on sunday, because they have to pull the building transformer
and replace it.. (Leaking pcbs.  Yay.)