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@xxxxxxxxx> 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- ---- 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
