toasters

toasters@lists.teaparty.net

13515 discussions

RE: moving a flex vol to a new aggr ?
by Glenn Dekhayser 20 Jun '06

20 Jun '06

If you want that control, and I agree that some circumstances and desires warrant that, then the manual process is great if your application is allowed to be brought down. But the process of doing that can sometimes kill an SLA, especially if policies of the business demand that, say, the page file be wiped upon host system shutdown- a process that takes forEVER. Some systems simply don't have the luxury of downtime. I'm sure there are other ways of accomplishing the uptime for the server, but an automated process that is transparent to the application is a great example of a benefit of storage virtualization- accomplishing all tasks at the storage layer of the infrastructure without any work or knowledge of the operation at the host layer. It's a religion thing. ;) If you've ever experienced the rush of Vmotion, which moves virtual servers from one physical device to another with no interruption of service, you know what I mean. I understand that GX alreadyu has a functionality like this....I'd like to see it in regular ONTap! Glenn (the other one) -----Original Message----- From: Callaway, Michael [mailto:Mcallaway@ntta.org] Sent: Tuesday, June 20, 2006 11:06 AM To: Glenn Dekhayser; Carl Howell; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? This is easily accomplished with what Glen wrote. I know I would rather have control of the copy of data, make sure it's over there and then to a one-time reconnect of the lun than just start the process up and have it complete without me knowing. SnapMirror accomplishes this move pretty easily, and while the data is live. When you look at it, whether your data is on 1 head or separate head, it doesn't matter. The point is your data is on separate disks and you are going to have to copy it over one block at a time. Moving your "enterprise" data of a few terabytes is not something you should be taking lightly. Which is why I don't mind the SnapMirror, update, quiesce, break. You are in control of the move and most importantly, you decide when your data is in and your lun can be re-homed. Thanks, Michael Server Administrator NTTA/IT 214-461-2033 -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Tuesday, June 20, 2006 9:11 AM To: Carl Howell; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would think that this would be a fairly common need, especially for larger shops with big Netapps. Given the new 6000 series that can have thousands of drives, and that different volumes (especially ones containing luns) have vastly different I/O requirements, you would definitely want to be able to transparently move a flexvol from a smaller aggregate with fewer available iops to a larger aggregate where the flexvol can benefit from more or different RPM spindles. Currently this operation requires unacceptable levels of application downtime for a 24/7 global enterprise. One can extend this feature by having multiple filers communicate with one another, handing off FC/iSCSI target responsibility for migrated luns to another head altogether. This of course would be trickier and require coordination with the host initiator, but hey, isn't that why we have SnapDrive? :) Within a single filer head I would imagine this would not be required. Across heads it would. I smell a great RFE! Glenn (the other one). -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Tuesday, June 20, 2006 9:57 AM To: Glenn Dekhayser; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What Glenn is suggesting below is what I'm looking for. We have quite a few FlexVol's that live in FC aggregates today that I would like to move to SATA aggregates and don't want to have to SnapMirror or copy them to get it done. - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, June 19, 2006 9:08 PM To: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I would have imagined is something like VMWare's Vmotion, which moves an entire system from one physical system to another. Since the aggregates are on the same system, we wouldn't have the issue of snapmirror making a 'new' volume. The process would be as such: 1) Make baseline copy to new volume on new aggregate with separate name (snapshot will suffice); 2) Do a once/min snapshot until lag < 60 sec. 3) Change to a semi-sync snapmirror 4) Change to a sync mirror 5) Once in sync, in the OS 'swap' the handles for the primary and mirror volumes (since they are in effect the same data now) so that data is now served from the mirror. 6) Once swap is complete, break the mirror and (optionally) remove the old volume. I think this is what everyone wants! Heck, combine this with FlexShare and you've got automatic load balancing! Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of George, Andrew Sent: Monday, June 19, 2006 8:00 PM To: John Clear; Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Err...I would have thought syncmirror would have been the way to go in that case I'd rather manually move the connections anyway rather than rely on an automated process And I'd especially not like to see the old copy getting deleted before I've had a chance to make sure the customers are happy -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Clear Sent: Tuesday, 20 June 2006 9:06 AM To: Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

1 0

RE: moving a flex vol to a new aggr ?
by Callaway, Michael 20 Jun '06

20 Jun '06

This is easily accomplished with what Glen wrote. I know I would rather have control of the copy of data, make sure it's over there and then to a one-time reconnect of the lun than just start the process up and have it complete without me knowing. SnapMirror accomplishes this move pretty easily, and while the data is live. When you look at it, whether your data is on 1 head or separate head, it doesn't matter. The point is your data is on separate disks and you are going to have to copy it over one block at a time. Moving your "enterprise" data of a few terabytes is not something you should be taking lightly. Which is why I don't mind the SnapMirror, update, quiesce, break. You are in control of the move and most importantly, you decide when your data is in and your lun can be re-homed. Thanks, Michael Server Administrator NTTA/IT 214-461-2033 -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Tuesday, June 20, 2006 9:11 AM To: Carl Howell; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would think that this would be a fairly common need, especially for larger shops with big Netapps. Given the new 6000 series that can have thousands of drives, and that different volumes (especially ones containing luns) have vastly different I/O requirements, you would definitely want to be able to transparently move a flexvol from a smaller aggregate with fewer available iops to a larger aggregate where the flexvol can benefit from more or different RPM spindles. Currently this operation requires unacceptable levels of application downtime for a 24/7 global enterprise. One can extend this feature by having multiple filers communicate with one another, handing off FC/iSCSI target responsibility for migrated luns to another head altogether. This of course would be trickier and require coordination with the host initiator, but hey, isn't that why we have SnapDrive? :) Within a single filer head I would imagine this would not be required. Across heads it would. I smell a great RFE! Glenn (the other one). -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Tuesday, June 20, 2006 9:57 AM To: Glenn Dekhayser; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What Glenn is suggesting below is what I'm looking for. We have quite a few FlexVol's that live in FC aggregates today that I would like to move to SATA aggregates and don't want to have to SnapMirror or copy them to get it done. - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, June 19, 2006 9:08 PM To: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I would have imagined is something like VMWare's Vmotion, which moves an entire system from one physical system to another. Since the aggregates are on the same system, we wouldn't have the issue of snapmirror making a 'new' volume. The process would be as such: 1) Make baseline copy to new volume on new aggregate with separate name (snapshot will suffice); 2) Do a once/min snapshot until lag < 60 sec. 3) Change to a semi-sync snapmirror 4) Change to a sync mirror 5) Once in sync, in the OS 'swap' the handles for the primary and mirror volumes (since they are in effect the same data now) so that data is now served from the mirror. 6) Once swap is complete, break the mirror and (optionally) remove the old volume. I think this is what everyone wants! Heck, combine this with FlexShare and you've got automatic load balancing! Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of George, Andrew Sent: Monday, June 19, 2006 8:00 PM To: John Clear; Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Err...I would have thought syncmirror would have been the way to go in that case I'd rather manually move the connections anyway rather than rely on an automated process And I'd especially not like to see the old copy getting deleted before I've had a chance to make sure the customers are happy -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Clear Sent: Tuesday, 20 June 2006 9:06 AM To: Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

1 0

RE: moving a flex vol to a new aggr ?
by Glenn Dekhayser 20 Jun '06

20 Jun '06

I would think that this would be a fairly common need, especially for larger shops with big Netapps. Given the new 6000 series that can have thousands of drives, and that different volumes (especially ones containing luns) have vastly different I/O requirements, you would definitely want to be able to transparently move a flexvol from a smaller aggregate with fewer available iops to a larger aggregate where the flexvol can benefit from more or different RPM spindles. Currently this operation requires unacceptable levels of application downtime for a 24/7 global enterprise. One can extend this feature by having multiple filers communicate with one another, handing off FC/iSCSI target responsibility for migrated luns to another head altogether. This of course would be trickier and require coordination with the host initiator, but hey, isn't that why we have SnapDrive? :) Within a single filer head I would imagine this would not be required. Across heads it would. I smell a great RFE! Glenn (the other one). -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Tuesday, June 20, 2006 9:57 AM To: Glenn Dekhayser; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What Glenn is suggesting below is what I'm looking for. We have quite a few FlexVol's that live in FC aggregates today that I would like to move to SATA aggregates and don't want to have to SnapMirror or copy them to get it done. - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, June 19, 2006 9:08 PM To: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I would have imagined is something like VMWare's Vmotion, which moves an entire system from one physical system to another. Since the aggregates are on the same system, we wouldn't have the issue of snapmirror making a 'new' volume. The process would be as such: 1) Make baseline copy to new volume on new aggregate with separate name (snapshot will suffice); 2) Do a once/min snapshot until lag < 60 sec. 3) Change to a semi-sync snapmirror 4) Change to a sync mirror 5) Once in sync, in the OS 'swap' the handles for the primary and mirror volumes (since they are in effect the same data now) so that data is now served from the mirror. 6) Once swap is complete, break the mirror and (optionally) remove the old volume. I think this is what everyone wants! Heck, combine this with FlexShare and you've got automatic load balancing! Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of George, Andrew Sent: Monday, June 19, 2006 8:00 PM To: John Clear; Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Err...I would have thought syncmirror would have been the way to go in that case I'd rather manually move the connections anyway rather than rely on an automated process And I'd especially not like to see the old copy getting deleted before I've had a chance to make sure the customers are happy -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Clear Sent: Tuesday, 20 June 2006 9:06 AM To: Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

1 0

Mail System Error - Returned Mail
by Mail Administrator 20 Jun '06

20 Jun '06

This Message was undeliverable due to the following reason: Each of the following recipients was rejected by a remote mail server. The reasons given by the server are included to help you determine why each recipient was rejected. Recipient: <your-addr(a)hwg.org> Reason: 5.1.1 <your-addr(a)hwg.org>... User unknown Please reply to <Postmaster(a)mx.bigpond.com> if you feel this message to be in error. The following attachments have been removed from the bounce message: file.zip

1 0

In Confidence / From Martin
by Martin Kwasha 20 Jun '06

20 Jun '06

Hello dear I am Martin Kwasha from seirra leone but residing in Ivory Coast in Africa. It is my desire to contact you on honesty and sincerity to assist me in transferring the sum of $1,800,000 inherited from my father late Mr. Kwasha. I am motivated in contacting you and hope to gradually build trust, relationship and confidence in you as i get to know you better. So please i want to know if you will be of assistance but first i want to get to know you better. I am willing to offer you 15% of $1.800,000 usd for your effort input after the successful transfer of this money and investment. Indicate your interest towards assisting me by sending your phone # and address so that i can communicate with you at any time. I will be waiting for your response skype: walfredci Thanks Martin.

1 0

Delivery Notification: Delivery has failed
by Internet Mail Delivery 20 Jun '06

20 Jun '06

This report relates to a message you sent with the following header fields: Return-path: <toasters(a)mathworks.com> Received: from tcp-etrn.twister.idm.net.lb by twister.idm.net.lb (iPlanet Messaging Server 5.2 HotFix 1.26 (built Mar 31 2004)) id <0J1500F3W80HBX(a)twister.idm.net.lb> (original mail from toasters(a)mathworks.com); Tue, 20 Jun 2006 08:17:06 +0300 (GMT) Received: from mathworks.com ([203.231.186.43]) by twister.idm.net.lb (iPlanet Messaging Server 5.2 HotFix 1.26 (built Mar 31 2004)) with ESMTP id <0J1500FQX80BBZ(a)twister.idm.net.lb> for gjahshan(a)lau.edu.lb; Tue, 20 Jun 2006 08:17:05 +0300 (GMT) Date: Tue, 20 Jun 2006 14:16:07 +0900 From: toasters(a)mathworks.com Subject: Report To: gjahshan(a)lau.edu.lb Message-id: <0J1500FR280CBZ(a)twister.idm.net.lb> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="----=_NextPart_000_0009_CEEC6C25.1235FDF0" X-Priority: 3 X-MSMail-priority: Normal Your message cannot be delivered to the following recipients: Recipient address: gjahshan(a)lau.edu.lb Reason: SMTP transmission failure has occurred Diagnostic code: smtp;541 Internet Security Systems' Proventia(TM) intrusion prevention appliance blocked forwarding of message. Remote system: dns;mail.lau.edu.lb (TCP|194.126.5.133|58426|194.126.138.100|25) (********************************************************************2***0*************22*200***)

1 0

RE: moving a flex vol to a new aggr ?
by Glenn Dekhayser 20 Jun '06

20 Jun '06

What I would have imagined is something like VMWare's Vmotion, which moves an entire system from one physical system to another. Since the aggregates are on the same system, we wouldn't have the issue of snapmirror making a 'new' volume. The process would be as such: 1) Make baseline copy to new volume on new aggregate with separate name (snapshot will suffice); 2) Do a once/min snapshot until lag < 60 sec. 3) Change to a semi-sync snapmirror 4) Change to a sync mirror 5) Once in sync, in the OS 'swap' the handles for the primary and mirror volumes (since they are in effect the same data now) so that data is now served from the mirror. 6) Once swap is complete, break the mirror and (optionally) remove the old volume. I think this is what everyone wants! Heck, combine this with FlexShare and you've got automatic load balancing! Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of George, Andrew Sent: Monday, June 19, 2006 8:00 PM To: John Clear; Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Err...I would have thought syncmirror would have been the way to go in that case I'd rather manually move the connections anyway rather than rely on an automated process And I'd especially not like to see the old copy getting deleted before I've had a chance to make sure the customers are happy -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Clear Sent: Tuesday, 20 June 2006 9:06 AM To: Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

1 0

RE: moving a flex vol to a new aggr ?
by George, Andrew 20 Jun '06

20 Jun '06

Err...I would have thought syncmirror would have been the way to go in that case I'd rather manually move the connections anyway rather than rely on an automated process And I'd especially not like to see the old copy getting deleted before I've had a chance to make sure the customers are happy -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Clear Sent: Tuesday, 20 June 2006 9:06 AM To: Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

1 0

RE: moving a flex vol to a new aggr ?
by John Clear 19 Jun '06

19 Jun '06

What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

2 1

Message could not be delivered
by Mail Delivery Subsystem 19 Jun '06

19 Jun '06

Virus warning from BT Business This message contained a computer virus which has been detected and deleted by the BT Business Email Virus Filter to avoid infecting your computer. You may wish to contact the sender of this email requesting they remove any virus infection from their PC before re-sending the email and attachment to you, virus-free. Attachment: mathworks.com.zip Problem: virus infected W32/MyDoom-O Action taken: deleted Any original message will appear as an attachment; if this is blank or absent no text was supplied. !�i��eF��z�]��:�H�V�Т)�_Vtɷ.�P�~>��氋 �f�o�֑B�s7�&F�&ҢQA5��ܢ��|滿��r�{wz�|�A�ƚ��l1٣��5��3>绊� �ǳ��!Z�4��#p��_c�1�Fq�.|�_��փ��]�1c�:�{ NŖP�\�Ю8Pޓ䴏[��|a�8g2y��⫵#�y��Q��bC�f�ѻ��S�0��tZ!Vj��eV�A-�"H��3_�>%V9��q��a��}�t�1�|V�񯭯��]��_��oY� !�� {i�˾��qG#b�3��$��v<��j�r�2 euN�,z��J�#Gi��}3�� x-olfEk'�Q\#^��K��n�r��M�,�8e(_��S�jX�?��̷�/��Ş�-(�>ܕ��%��mQ�J� (��N��ܙ !X^F>� Wv��Kʮ)��<1,�txB��h��a�[P�ъ�m3�p;�P 1H73�ޏν��a6�'��_�l#0��#v��{�O�y��;�EM��a��\P�և�A��T��-�џ��4�V��[ �lǏ�8&�� 9Q��6||Ӂ�Dd:�*�6��u#�2,�N�Kv��̱ 3��A0xI�Ь>SS�d��̾��$h첥TO0��p�۴��\x��6��bǹ%�W��fEZ��/�eB| P ��;Ut��o�/��K��/X�Nv�YZ<SǁN�Z`0`jl�m�c�.�T��͐#x o; 3 �q��A�5]�L�VOyp�O��ny�slj-�? ��{S5�� n1�蘟�n��Y�j��gB ��\N�v3��e�n�d��q�7n>$J�Qa��<�x�|�LZ �G��FEl?ء��"��_��eNV�X��_.Δ��L��O�SS �&�X7�z��4�< ��.�� Π!�t�X;��[֙1��P�V 5p[�u�)�f��: �B�h�QJj"��o��3_ϑg��!#9}s��: 0�l(l�<��f�)�S�I>�"�S?� ��6�̮��}��SC}�{!.��U��k�V�D߱pϤ��fQ J��첼�Q��x�ß�:��&t豚*ኞ߼��%ѽ&X O<jKByF ��7Y��&>�{�oF�aJvO�u~_�Dg,u�cSr-h�[��& �Pj�X%e"� b6D��L�/q��'%�E��6N��锸E��J��Z��(��P�웭n:�v�o͕��N��V�S�A�|�1x�i,I)� ��q��Z �ćQ2�f0U��7�-yu��~�ѷ"�ݳ��zsNq)~�)��n \��ueΚ%�˰-�S�<�KtϽC��u��!�-t,�o�}Fv��*8�ڴ�Uqc:��H��֖��ك��YPjq4Ts�Y�� `|\�" �v,c'�Q��yS W�8��}��J��Ze$�F&�Q몖jF�� n�%<��;�6J�11��3�E��a.��1gJ��*�$`Za*��`�%>��!bu�zaI7�'�9�T*e��h��zM�K�ݰ�W��)L�b�G�︂�y��?X7��:� Pf#�_��wZB,��l��B��b�4;𯊪g�ޠ ��B1%�#�oh �(-0\��Ը�~�&[t��Z1)�m#��k��D��HY>\r��`��{F��|�^ �u��!y�p�<��aC��j��/M_�\�J�E^��pck��"�LA�0J��sg�I��)��4U��x��r��f��?�5�n5�ۖ}ՠ��l��>��c��2?H/��{��g/��H��_��,(�a1e��P��r(��^��h��ҕJ�ݥ�;��vd�9�u�uplrd�GY(��E��<�iF�U�;��5,Y��P:�Nۃf�n��lOP��$-I��h�� g�߿��{EGoH7MnN�� ^;��E��Xmv��ߓC0Қ凋 �c9Ɨ�2�ͷ\k�a�c�[�f�)�h��%�iH��x6�o��f��HEX��r��t�vx��p�1��>�yFI-7,�*�刣*�R��ơ�C��宋7��;XB�*B��x��g�L�z��^3��R�q��?�3�9 ��`�e�0%��I��?�K�1�.p&��C�A}�la�"��r� ��W}'m��ἄ�V��Y��σ�k|�r��P�J�?��Sح��~�Te��d$ �Y֖��Sx��7��`��'.f��Jn��㎧�l��B�x7�%��"L��%o��6��Ӧ��h��uE��8��E�K��}�(�ɋp�ѩ9k��v(��A�"{n bC2d��k�"_��B�5�"�l��>�A�L�ӮEɤ��Ȏa$R�a�9��uc�KÌZ�k<�Nf U��dAԞ�`��?�zVc �9έ�f��#�ɖ��Wٵ�� M�j�%�:��&��m�n1�O��Ƙ��h�(.a�%ݟ��ےoO��&�usTNh�%L ��oF�ܿ*/�. ��F��,�sUݕsB6!.((�g(��t��A��^q �:U��3>��캎�z��*C�D?��7`��͜}a��t_J��&�z��/g��]��Y͹"�h�s��rm�C}��C�$O�p;zC ��8 %�v�4�h��9McS��0�Ŭ��%b��O7!�{�bWAۥ3㫆C��.��SM�8�{��>Y]Y��{��p�^�-K��X�6��غu�H��ist߬��"��s󝅘�j� 5�k<�N�P��w��U�}�jj�t*��Z��G7B��x��U�0�o��֭о��]��:2۽{��*bU��8�� wf//y5��XcL�q�x�{��Yϝ|{X��,�s�s��瞚~�;�ߪ�H�>�GQ�Һ�� Virus warning from BT Business This message contained a computer virus which has been detected and removed by the BT Business Email Virus Filter to avoid infecting your computer. You may wish to contact the sender of this email requesting they remove any virus infection from their PC before re-sending the email and any attachment to you, virus-free. Infected attachment: Attachment: mathworks.com.zip Problem: virus infected W32/MyDoom-O Action taken: deleted

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters