> Ramprasad wrote, on 19.10.2011 15:37: >> I think , writing a standalone index upgrade utility , like the ipurge , >> seems to be a reasonable thing to do >> >> >> If there was a light enough index upgrade possible ( only for inboxes .. >> not subfolders ) Then I could stop cyrus , fork probably around 100 >> parallel upgrades take a 2-3 hour downtime and then start services again > > Currently I'm considering the following way: > *) build a new backend with same partition count/names > *) output something like > "find ../partxx -type -f -links +2 -ls |sort" to a file for every > partition > on the old backend. -ls maybe replaced by special -printf. > *) move mailboxes from 2.3 to 2.4 with rename keeping partitions the same > *) write a script reading "find"-output and relink all the files with same > inodes. This can be done at any time and with low impact. > > I think that should be pretty safe if the script has enough safty belts in > place. Mails moved or deleted in the meantime are a special case. Don't > know > if it's worth to try hard to find them. I think for the singleinstancestore, you can redo it after migration with tools like hardlink or http://www.freedup.org/. IIRC I did this once and it worked fine - I think I was using a simple bash script as you suggested above. The only problem could be that you need the extra space while migration is going on. Simon ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
