I'd like to second that question: we used snapmirror to copy a vol of 18's to 7x72 on a ds14, but it hasn't been attached to the production filer yet. Snapmirror, because vol copy and ndmpcopy both failed, source filer was at 536R1 and dest was 613.
-----Original Message----- From: Boris Khmelniker To: toasters@mathworks.com Sent: 8/5/02 1:25 PM Subject: Migration question
Hello, We are going to migrate data from 10 9GB shelves (2 Volumes) to 1 DS14 shelf (14 72GB disk) (also 2 volumes) on the F760 filer running DATAONTAP 6.1.1. Downtime allowed is minimum (4 hours). I was planning to use SnapMirror but worrying about fragmentation it will cause because of the difference in disk size. Any thoughts on that are appreciated. Thank you, Boris
It's not truly fragmentation but a matter of bit ordering. Snapmirror's bit order is 1 to end-of-source-drive, then continue if dest drive still has room. So, if you are going from 9gb drives to 72gb drives, you're going to have serious issues. What will happen is all data from the first 7 or 8 drives (depending on BC or ZC drives) will all be put onto the first 72gb drive.
I found out the hard way, 18gb drives to an r100 with 136gb drives. Couldn't figure out why my backups from the r100 were so slow; that would be why.
In my case, what would normally be 7 stripes across seperate drives became 7 stripes located non-sequentially on one drive.
~JK
"Toal, Dave" wrote:
I'd like to second that question: we used snapmirror tocopy a vol of 18's to 7x72 on a ds14, but it hasn't been attached to the production filer yet. Snapmirror, because vol copy and ndmpcopy both failed, source filer was at 536R1 and dest was 613.
-----Original Message----- From: Boris Khmelniker To: toasters@mathworks.com Sent: 8/5/02 1:25 PM Subject: Migration question
Hello, We are going to migrate data from 10 9GB shelves (2 Volumes) to 1 DS14 shelf (14 72GB disk) (also 2 volumes) on the F760 filer running DATAONTAP 6.1.1. Downtime allowed is minimum (4 hours). I was planning to use SnapMirror but worrying about fragmentation it will cause because of the difference in disk size. Any thoughts on that are appreciated. Thank you, Boris
One caveat to this is qtree snapmirroring. There is no bit ordering problem if you do it by qtrees in OT 6.2+.
~JK
Jeff Kennedy wrote:
It's not truly fragmentation but a matter of bit ordering. Snapmirror's bit order is 1 to end-of-source-drive, then continue if dest drive still has room. So, if you are going from 9gb drives to 72gb drives, you're going to have serious issues. What will happen is all data from the first 7 or 8 drives (depending on BC or ZC drives) will all be put onto the first 72gb drive.
I found out the hard way, 18gb drives to an r100 with 136gb drives. Couldn't figure out why my backups from the r100 were so slow; that would be why.
In my case, what would normally be 7 stripes across seperate drives became 7 stripes located non-sequentially on one drive.
~JK
"Toal, Dave" wrote:
I'd like to second that question: we used snapmirror tocopy a vol of 18's to 7x72 on a ds14, but it hasn't been attached to the production filer yet. Snapmirror, because vol copy and ndmpcopy both failed, source filer was at 536R1 and dest was 613.
-----Original Message----- From: Boris Khmelniker To: toasters@mathworks.com Sent: 8/5/02 1:25 PM Subject: Migration question
Hello, We are going to migrate data from 10 9GB shelves (2 Volumes) to 1 DS14 shelf (14 72GB disk) (also 2 volumes) on the F760 filer running DATAONTAP 6.1.1. Downtime allowed is minimum (4 hours). I was planning to use SnapMirror but worrying about fragmentation it will cause because of the difference in disk size. Any thoughts on that are appreciated. Thank you, Boris
--
Jeff Kennedy Unix Administrator AMCC jlkennedy@amcc.com
-
Jeff Kennedy -
Toal, Dave