> Hello, > > > I am having trouble converting a quota skiplist db back to quotalegacy > format (I know... this is probably not the most common Cyrus operation :-) > > % cvt_cyrusdb /ssd/cyrs/imap/quotas.db skiplist /ssd/cyrs/imap/quota > quotalegacy > Converting from /ssd/cyrs/imap/quotas.db (skiplist) to > /ssd/cyrs/imap/quota > (quotalegacy) > % find quota -type f | wc -l > 126 > % strings quotas.db|wc -l > 135229 > > > "quotas.db" was created using the reverse operation and took about one > minute. > I renamed the original 'quota' directory out of the way before making the > second cvt_cyrusdb call. > > Closer inspection of the newly created 'quota' directory reveals 125 quota > descriptor files named user.aXXXXXX created under 'a', all relating to > existing top level mailboxes and containing the correct information, and > (curiously) one file named 'u' in directory 'u'. > > I also tried a Berkeley DB intermediate format and the creation > of the quotalegacy structure failed in an identical way. I expect this to be a bug in the way cvt_cyrusdb calls the quotalegacy backend, or in the backend itself. And I guess you are the first to test it out :) Could test it with different dirhashing options to found out how exactly it fails? Simon > > > Other question : would I be better off with 65,000 small files > (quotalegacy) in a one-level hash or with a single skiplist db > for my quota information, when the files reside on solid state > storage anyway ? > > > Thx, > Eric Luyten, Computing Centre VUB/ULB. > > ---- > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
