On Thu, Jun 18, 2009 at 05:44:19PM -0400, Michael Bacon wrote: > Another one stomped here. This time, it's a 32/64 bit issue. myinit in > cyrusdb_skiplist.c assumes that type_t is 4 bytes long, and writes out > that many from the current timestamp when creating $confdir/db/skipstamp. > On 64-bit Solaris, time_t is 8 bytes (it's typedef'ed as a long). I'm > forgetting my Who's Who of big and little endian chips, but my guess is > that on x86 systems, the first four bytes are the ones with the real data > in them, so there's actually meaningful data that gets written out. On > Sparc, though, no such luck. Er, yeah. Ouch. Damn. I want to make it an 8 bit value, but that would be an incompatible format change to skiplists. At which time I would do a bunch of other stuff too. I do have a cyrusdb_skiplist2.c file floating around somewhere that does it (checksums for one thing). I was even thinking of doing something really evil with ordering on checkpoint, but I never got around to running the numbers to see if it made point. Basically instead of: level: 1 2 1 3 2 1 1 2 key : aaa bbb ccc ddd eee fff ggg hhh It would lay the records out like this: level: 3 2 2 2 1 1 1 1 key : ddd bbb eee hhh aaa ccc fff ggg The advantage being that for a lookup, the "next record" at the same level would be directly after the current one, so readahead would be more likely to hit the next node for the search case. It would be a fair bit more random for enumerating though, so I don't know if it's really sane (and of course as you make changes, it all gets more random until the next checkpoint anyway) So anyway, will definitely fix the immediate issue! Thanks, Bron. ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
