Is skiplist dependant on byte order?

[Gary Mills]

On Mon, Jun 16, 2008 at 10:18:47PM +1000, Bron Gondwana wrote:
> 
> On Mon, 16 Jun 2008 03:29:25 -0700, "Scott Likens" <damm at yazzy.org> said:
> > I'm going to take a shot in the dark,
> > 
> > BIG Endian vs. Little Endian?
> 
> Skiplist has had quite a lot of care taken to use network order for
> all values.  I don't _believe_ there are any issues.

Perhaps I had an older version, or I didn't do it quite correctly.

> > Unfortunately I do believe bdb databases do care if it was big or  
> > little... and going from Sparc (BIG) to x86 (little)...
> >
> > Would not work very well :(
>  
> Yeah - they are pretty version and system specific.  I would always
> dump BDB databases for a transfer.  Certainly crossing architectures.

Yes, I omitted those from my original message because I also did a
version upgrade on BDB; I expected problems there.  Fortunately,
they were all empty on my murder front end, so I just deleted them
after my test on mailboxes.db.

> > I am going to guess that a reconstruct may not be a bad idea, your  
> > seen databases may or may not work, and pretty much guess that any and  
> > all databases related to Cyrus will need to be re-worked... I'm sure  
> > someone like Bron (fastmail.fm) might have something already whipped  
> > up for this.

> > Seen should be in /var/imap/user
> > ... I would check on sieve (it is compiled also) ... (/var/imap/sieve?)
> 
> Yeah, recompiling your sieve files doesn't sound like a bad idea at all.

There are no mailboxes on my murder front end, so these shouldn't exist
either.  I'm not upgrading the back end this time around.

> > then the /var/spool/imap/a/user/.. and you can more then likely just  
> > do a reconstruct -rf and be fine...
> 
> That's a serious amount of IO.  All the index and cache files are
> supposed to be endian-clean as well.  It's all htonl and ntohl everywhere.

Again, these shouldn't exist on the front end.

> > On Jun 15, 2008, at 6:38 PM, Gary Mills wrote:
> 
> (there's more below)
>  
> > > I recently upgraded a murder front end server from Solaris 9 SPARC to
> > > Solaris 10 x86 by copying the /imap directory.  I did dump the
> > > mailboxes database before the copy.  It's a skiplist database.  I'm
> > > running cyrus-imapd-2.3.8 on both systems.  As a test, I first checked
> > > on the mailboxes database like this:
> > >
> > >    # su cyrus -c ksh
> > >    # /usr/local/cyrus/bin/ctl_mboxlist -d | wc -l
> > >           0
> 
> Do you have cyr_dbtool in that version?  I can't remember when it got
> take upstream.  dbtool is nice because it dumps all the cyrus databases,
> not just the mailboxes.db.

I don't believe so.

> > > This message appeared in the log:
> > >
> > >    Jun 11 16:24:43 setup01 ctl_mboxlist[14082]: [ID 864961  
> > > local6.crit] DBERROR: critical database situation
> 
> That sounds like BDB to me.  Are you running BDB mailboxes.db?  That would
> certainly explain it.

The mailboxes database certainly is skiplist, but perhaps there was some
other involved as well.  I actually got two messages.  They do sound like
BDB errors:

  Jun 11 16:24:43 setup01 ctl_mboxlist[14082]: [ID 866726 local6.warning] DBERROR db4: PANIC: fatal region error detected; run recovery
  Jun 11 16:24:43 setup01 ctl_mboxlist[14082]: [ID 864961 local6.crit] DBERROR: critical database situation

> > > After I reloaded it, I got the correct output:
> > >
> > >    # /usr/local/cyrus/bin/ctl_mboxlist -u < mailboxes.txt
> > >    # /usr/local/cyrus/bin/ctl_mboxlist -d | wc -l
> > >          77

These commands generated four log messages.  I renamed and recreated the
`db' directory before running them, and of course renamed `mailboxes.db'.

  Jun 11 16:29:34 setup01 ctl_mboxlist[14091]: [ID 143423 local6.error] DBERROR: reading /imap/conf/db/skipstamp, assuming the worst: No such file or directory
  Jun 11 16:29:35 setup01 ctl_mboxlist[14091]: [ID 275131 local6.notice] skiplist: recovered /imap/conf/mailboxes.db (0 records, 144 bytes) in 0 seconds
  Jun 11 16:29:57 setup01 ctl_mboxlist[14093]: [ID 143423 local6.error] DBERROR: reading /imap/conf/db/skipstamp, assuming the worst: No such file or directory
  Jun 11 16:29:57 setup01 ctl_mboxlist[14093]: [ID 275131 local6.notice] skiplist: recovered /imap/conf/mailboxes.db (77 records, 8460 bytes) in 0 seconds

> > > I'm assuming that skiplist is dependant on the machine's byte order,
> > > and that a dump and reload is necessary in this case.
> 
> No, it really shouldn't matter.  One of the good things about the skiplist
> design.  There are other bits that aren't so good - but the byte order
> part is nice.

I'm not clear which parts of the `db' directory are associated with
skiplist databases and which with BDB databases.

> > > Are there any other databases that I should also dump and reload?  As
> > > far as I can tell, the annotation_db, duplicate_db, and tlscache_db
> > > are empty and can simply be removed.  Are there any others on a murder
> > > front end that I've missed?  Where do they reside?
> 
> Yeah, we nuke all those on restart.  duplicate_db is the most interesting
> of that lot - but not a giant concern.  It will cause vacation messages to
> be repeated, and duplicate messageids to be delivered if it's gone - that's
> about all.  For a once-off I wouldn't be at all concerned.
> 
> mailboxes.db really is the big one.  Anything else with berkeley named in it
> that's either in your imapd.conf or defaulted that way in lib/imapoptions.

Thanks.  Upgrade of the production front end is looking easier.

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-