Well, I have just tried a local qsm, a break and then a vsm to cdot.
That seemed to work, but I am not sure if the resync will work sufficiently well, but obviously I need to be able to resync to do a differential copy.
I might do this and then rsync (or xcp) to catch up.
On 25 Aug 2016 12:00, "Basil" basilberntsen@gmail.com wrote:
I had the same issue and was able to force the TDP relationship to sync (I forget how, but it was hacky), and the CDOT volume got corrupted. I needed to open a ticket to even delete it. That freaked me out and I decided to take a double outage window.
On Thu, Aug 25, 2016 at 6:06 AM, Edward Rolison ed.rolison@gmail.com wrote:
I'm migrating a bunch of volumes from a 7 mode filer, to CDOT.
For various reasons, I'd _like_ to split these volumes apart prior to migration - mostly around filecount. We have a few qtrees with really high file counts, and generally they don't make sense to group together anyway.
So - what I'm thinking is:
QSM from source qtree to 'staging' volume within filer. VSM from staging volume to CDOT TDP volume.
Should I be able to do this, or is there a better way?
Ideally - I'd like to avoid a 'double cutover' scenario. My 'plan B' involves just creating about 10 replicas of the source volume, and - post cutover - delete all the stuff I didn't need from each of them, but this seems a suboptimal solution. (I think I have the same problem, in that I can't lower the inodes of the volume, so I'll have 10 volumes with 100M+ inodes, instead of 10 with considerably fewer)
It certainly seems like a TDP snapmirror doesn't work when a QSM is inbound to the volume in question - but a break and resync _might_ do the trick? (trying to do that now)
Is there a better approach I should be taking?
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters