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