To clarify, the setup I was testing was a QSM between volumes in 7-mode, deleting the QSM and shared snapshots on those two volumes, then trying to sync a transition snapmirror between the former QSM target and CDOT. The issue was that I couldn't sync the transition snapmirror while QSM was active, and forcing it (I forget how) caused corruption in CDOT.
XCP is, like you said, only NFS. If the files are NTFS, which is usually the case, splitting volumes can only be done with a snapmirror to a new volume then deletion of the files in the volume outside the targeted folder/qtree. Deleting high file count data will take a long time, and depending on the volumes involved, there might not be sufficient room to double up like this.
The last option is a robocopy. You can multithread these to reduce the outage window, but it's going to be a long outage.
On Thu, Aug 25, 2016 at 7:08 AM, Michael Bergman < michael.bergman@ericsson.com> wrote:
On 2016-08-25 12:06, Edward Rolison 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.
Splitting up file trees that have grown too large in this way is often desirable when migrating, but you should avoid doing it with this messing around with QSM and VSM. Instead you should best use the NetApp tool xcp, which was created for the purpose of effective 7m -> C.DOT migration of data. It works over NFS, so there's no problem with compatibility.
With this you can use a suported SnapMirrir 7m -> C.DOT for the bulk of the data, pick out parts that you do with xcp and then delete the superflous files afterwards (when it has landed on C.DOT, after your cut over window). Hopefully you have some extra swing space to be able to pull this off, if not then...
Yes, I know it's daunting w.r.t. Very High Filecount. But it's still the best way IMO... rsync is impossible due to the traversing of all the inodes it does every single time on source and target, xcp keeps track of a state that avoids this and it has its own NFS stack built in, which makes it a very different and effective animal than anything else I've ever seen or herad of
/M
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