ok, sorry, and fanku i learned something today
Kennedy, Jeffrey wrote:
Actually, that is exactly what it will do. I had the snapmirror dev team lead at my previous employer for a day trying to figure out why backups of snapmirror'd volumes on an R100 were so damn slow.
The block transfer is done similar to the following:
36gb drive has blocks 1 through 10,000. 144gb drive has blocks 1 through 80,000. (example numbers only)
snapmirror will transfer all blocks on the first drive of source to first drive on destination. It realizes there is available space still on destination drive and transfers second drive in source to first drive in destination. Given the example numbers it will transfer the first 7 drives in the source volume to the first drive in the destination.
This is confirmed by NetApp. Qtree snapmirroring does not behave this way, only volume snapmirroring.
~JK
-----Original Message----- *From:* owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] *On Behalf Of *Stephane Bentebba *Sent:* Wednesday, August 13, 2003 4:25 AM *Cc:* toasters@mathworks.com *Subject:* Re: NDMPcopy and fibre disk shelve file copy.
snapmirror won't copy data in filing up one disk then another then another and leave the last disk empty . new data won't be written only in the last disk
data are copied and written in all disk in // therefore all disk would have the same free space
the only impact on data there is (and it is a good impact) is the fragmentation that is reduced reading a file can be made faster because blocks of that file are contiguous
Reinoud Reynders wrote:
You must take attention with snapmirror. When you do a vol snapmirror
from little disks to larger disks, you can have some problem with
fragmentation.
The free space in every disk will not be on the same place on the new
disks (he will use the new disks sequential to load the old disks so
that the first disks of your new volume will be totaly full), so it's
harder to write new data on the same level. This will mean that when
your source volume and destination volume have almost the same size,
after migration there is a high change that he will use just one disk of
your raid group (the last one) for the new data. All your old data is
writen to the first disks. This can give performance issues. Of course,
this problem is biger when the source volume is full.
We use QTREE snapmirror, but we are'nt sure that this is better, but we
hope that it is. But your source data must be in qtree's ofcourse.
Best regards,
Reinoud
UZ Leuven
Belgium
-----Original Message-----
From: Joseph Bishop [mailto:jbishop@jpl.nasa.gov]
Sent: vrijdag 1 augustus 2003 8:08
To: Ngoh, Clarence
Cc: toasters@mathworks.com mailto:toasters@mathworks.com
Subject: Re: NDMPcopy and fibre disk shelve file copy.
Clarence,
IAre the disks within the same box? If not...then snapmirror is a good
way to go. You might be able to snapmirror within the same box.
Performance really depends on how many disks you have in the volume(s)
and what kind of head (700, 800, 900) that you have.
If you are able to snapmirror, then the down time can be on the order of
minutes. It has become my favorite method for moving data. I am not
positive about the source and destination being on the same box though.
Rough numbers though, you could get 60MByte/sec xfer rate on 820s. If
you are on 960s expect to be on the order of 120MBytes/sec. But then it
does depend on how many drives in the raid group and volumes.
Joe
Ngoh, Clarence wrote:
Hello good toaster folks
We are planning to move a huge lot of data (> 3.0 T) from our 32 GB
drives to 144 GB. I am carrying out some preliminary information about
the quickest path to move the data across - the first option is to use
ndmpcopy
and the second is to copy it from shelf to shelf over fiber. Since
this is
a preliminary investigation, can someone please point me to relevant
resources that may be helpful? I am after statistics of transfer
rates
between the two and perhaps other materials that others have found
useful.
I have googled and looked through past toaster archives, and most of it
is either outdated or lack of relevant information.
Thanks.
Clarence.
************** IMPORTANT MESSAGE **************
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. If you are not the intended
recipient please advise the sender by return email, do not use or
disclose the contents, and delete the message and any attachments from
your system. Unless specifically indicated, this email does not
constitute formal advice or commitment by the sender or the Commonwealth
Bank of Australia (ABN 48 123 123 124) or its subsidiaries.
--
-- jetez un oeil ici http://www.sensiva.com/ --
-- have a look here http://www.sensiva.com/ --
-
Stephane Bentebba