Mailing List Archive

Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'?
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?
Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
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
>
>
Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
Sounds about right. there is no QSM into or on cDOT.

The other option you have, if space is not an issue, you could do multiple
VSM and then delete what you do not want in each.

Use 8.3 or higher and the Snapmirror transition guide in the Documents
section and no need to worry about it be "hacky" as Basil indicated in his
use.

--tmac

*Tim McCarthy, **Principal Consultant*

*Proud Member of the #NetAppATeam <https://twitter.com/NetAppATeam>*

*I Blog at TMACsRack <https://tmacsrack.wordpress.com/>*




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
>
>
Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
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
Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
On 2016-08-25 13:05, tmac wrote:
> The other option you have, if space is not an issue, you could do multiple
> VSM and then delete what you do not want in each.

I agree.
Using this method, in combination with xcp, is probably the smartest but it
can take a good bit of work to set it all up and figure it out -- so you
know you can handle your [one single] change windows

> Use 8.3 or higher and the Snapmirror transition guide in the Documents
> section and no need to worry about it be "hacky" as Basil indicated in
> his use.

I concur

/M
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
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
>
Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
DAMN! How'd I forget about that!

As long as you have NFS access (and there are no CIFS ACLs on the files)
XCP is the bomb!

VERY VERY fast

http://mysupport.netapp.com/tools/info/ECMLP2357425I.html?productID=62115

--tmac

*Tim McCarthy, **Principal Consultant*

*Proud Member of the #NetAppATeam <https://twitter.com/NetAppATeam>*

*I Blog at TMACsRack <https://tmacsrack.wordpress.com/>*


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
>
Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
I've found that the ratio of NTFS to Unix permission styles in the shops
I've worked at is very high. XCP is extremely interesting, but still a tool
with a limited surface area.

On Thu, Aug 25, 2016 at 7:18 AM, tmac <tmacmd@gmail.com> wrote:

> DAMN! How'd I forget about that!
>
> As long as you have NFS access (and there are no CIFS ACLs on the files)
> XCP is the bomb!
>
> VERY VERY fast
>
> http://mysupport.netapp.com/tools/info/ECMLP2357425I.html?productID=62115
>
> --tmac
>
> *Tim McCarthy, **Principal Consultant*
>
> *Proud Member of the #NetAppATeam <https://twitter.com/NetAppATeam>*
>
> *I Blog at TMACsRack <https://tmacsrack.wordpress.com/>*
>
>
> 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
>>
>
>
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> http://www.teaparty.net/mailman/listinfo/toasters
>
>
Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
On 2016-08-25 13:17, Basil wrote:
> XCP is, like you said, only NFS. If the files are NTFS, which is usually
> the case,

Very true. I'm in a world where the opposite is true:
"If the files are NFS, which is usually the case"..."

I'm sorry.

> 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.

I concur.

> 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.

Yes, but that would not matter (how long it takes) if there's enough "extra
space" so to speak. It could take days, a week... no one will really care,
right? The only thing that could be bad, is if the target C.DOT node is
small. File deletes pressure WAFL quite a lot, you can get performance
issues and W latency can shoot up. A lot, in the worst case, due to massive
amounts of small file deletes


> The last option is a robocopy. You can multithread these to reduce the
> outage window, but it's going to be a long outage.

Robocopy is one of the tools available for handling CIFS (NTFS) data. There
are a few others, but I have not tried any of them exept this one and it
works really well (at least then, it was many years ago now).

<http://www.xxcopy.com/xcpywhat.htm>

This SW is still actively developed, alive and kicking, so this is what I
would use if I had to do CIFS/NTFS file copying this way

/M

> On Thu, Aug 25, 2016 at 7:08 AM, Michael Bergman
> <michael.bergman@ericsson.com <mailto: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 <mailto:Toasters@teaparty.net>
> http://www.teaparty.net/mailman/listinfo/toasters
> <http://www.teaparty.net/mailman/listinfo/toasters>
>
>

--
Michael Bergman
Sr Systems Analyst / Storage Architect michael.bergman@ericsson.com
Engineering Hub Stockholm Phone +46 10 7152945
EMEA N, Operations North, IT Ops Kista SMS/MMS +46 70 5480835
Ericsson Torshamnsg 33, 16480 Sthlm, Sweden
--
This communication is confidential. We only send and receive email on the
basis of the terms set out at www.ericsson.com/email_disclaimer
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
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
>>
>>
>
RE: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'? [ In reply to ]
XCP support for NTFS is being worked on, FWIW. :)

-----Original Message-----
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Michael Bergman
Sent: Thursday, August 25, 2016 7:33 AM
To: Toasters
Subject: Re: Snapmirror TDP from 7mode to CDOT - Can I 'daisy chain'?

On 2016-08-25 13:17, Basil wrote:
> XCP is, like you said, only NFS. If the files are NTFS, which is
> usually the case,

Very true. I'm in a world where the opposite is true:
"If the files are NFS, which is usually the case"..."

I'm sorry.

> 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.

I concur.

> 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.

Yes, but that would not matter (how long it takes) if there's enough "extra space" so to speak. It could take days, a week... no one will really care, right? The only thing that could be bad, is if the target C.DOT node is small. File deletes pressure WAFL quite a lot, you can get performance issues and W latency can shoot up. A lot, in the worst case, due to massive amounts of small file deletes


> The last option is a robocopy. You can multithread these to reduce the
> outage window, but it's going to be a long outage.

Robocopy is one of the tools available for handling CIFS (NTFS) data. There are a few others, but I have not tried any of them exept this one and it works really well (at least then, it was many years ago now).

<http://www.xxcopy.com/xcpywhat.htm>

This SW is still actively developed, alive and kicking, so this is what I would use if I had to do CIFS/NTFS file copying this way

/M

> On Thu, Aug 25, 2016 at 7:08 AM, Michael Bergman
> <michael.bergman@ericsson.com <mailto: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 <mailto:Toasters@teaparty.net>
> http://www.teaparty.net/mailman/listinfo/toasters
> <http://www.teaparty.net/mailman/listinfo/toasters>
>
>

--
Michael Bergman
Sr Systems Analyst / Storage Architect michael.bergman@ericsson.com
Engineering Hub Stockholm Phone +46 10 7152945
EMEA N, Operations North, IT Ops Kista SMS/MMS +46 70 5480835
Ericsson Torshamnsg 33, 16480 Sthlm, Sweden
--
This communication is confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer _______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters