toasters

toasters@lists.teaparty.net

13517 discussions

YOUR URGENT RESPONSE IS NEEDED
by Jennifer Leary 20 Jun '06

20 Jun '06

FROM: Sgt. Jennifer Leary To whom it may concern. I am an American soldier, I am serving in the military of the 1st Armored Division in Iraq, as you know we are being attacked by insurgents everyday and car bombs. We managed to move funds belonging to Saddam Hussein's family. The total amount is US$7.2Million dollars in cash, mostly 100 dollar bills. We want to move this money to you, so that you may invest it for us and keep our share for banking.We will take 60%, my partner and I. You take the other 40%. No strings attached, just help us move it out of Iraq, Iraq is a war zone. We plan on using diplomatic courier and shipping the money out in one large silver box, using diplomatic immunity. If you are interested I will send you the full details, my job is to find a good partner that we can trust and that will assist us. Can I trust you? When you receive this letter, kindly send me an e-mail signifying your interest including your most confidential telephone/fax numbers for quick communication also your contact details. This business is risk free. The box can be shipped out in 48hrs. Respectfully, Sgt. Jennifer Leary Private Email: jenniferleary25(a)aim.com SPANISH LANGUAGE DE: Sgt. Jennifer Leary A quien pueda interesar. Soy soldado americano, Estoy desempen'ando servicios en los militares del Primero División armada en Iraq, como usted sabe cerca nos están atacando insurrectos diarios y bombas de coche. Manejamos mover los fondos que pertenecían a la familia de Saddam Hussein. la cantidad total es dólares de US$7.2Million en efectivo, sobre todo 100 cuentas de dólar. Deseamos mover este dinero a usted, de modo que usted pueda invertirlo para nosotros y guarde nuestra parte para las actividades bancarias.Tomaremos el 60%, mi socio y yo. Usted toma el otro 40%. Ningunas secuencias unidas, justo ayúdenos a moverlo de Iraq, Iraq es una zona de la guerra. Planeamos en usar el mensajero diplomático y enviar el dinero hacia fuera en una caja de plata grande, usar inmunidad diplomática. Si usted soy interesado le enviaré los detalles completos, mi trabajo está al hallazgo a buen socio a que podemos confiar en y que nos asistirá. ¿Puedo confiarle en? Cuando usted recibe esta letra, amablemente envíeme significar del E-mail su interés incluyendo su teléfono más confidencial números de fax para comunicación rápida también sus detalles del contacto. Este negocio es riesgo libremente. La caja se puede enviar hacia fuera en 48hrs. Respetuosamente, Sgt. Jennifer Leary Email Privado: jenniferleary25(a)aim.com FRENCH LANGUAGE DE : Sgt. Jennifer Leary À qui de droit. Je suis un soldat américain, Je sers dans les militaires du 1er Division blindée en Irak, comme vous savez nous sommes attaqués près insurgés journaliers et bombes de voiture. Nous sommes parvenus à déplacer des fonds appartenant à la famille de Saddam Hussein. le montant total est des dollars d'USS7.2Million comptant, la plupart du temps 100 billets d'un dollar. Nous voulons déplacer cet argent à vous, de sorte que vous puissiez l'investir pour nous et gardez notre part pour des opérations bancaires.Nous prendrons 60%, mon associé et I. Vous prenez l'autre 40%. Aucunes cordes jointes, juste aidez-nous à le déplacer hors de l'Irak, L'Irak est une zone de guerre. Nous projetons sur employer le courier diplomatique et l'expédition l'argent dehors dans une grande boîte argentée, employer l'immunité diplomatique. Si vous suis intéressé je vous enverrai les détails complets, mon travail est à la trouvaille a bon associé au lequel nous pouvons faire confiance et qui nous aidera. Est-ce que je peux vous faire confiance ? Quand vous recevez cette lettre, nous vous saurions gré de m'envoyer signifier de E-mail votre intérêt comprenant votre téléphone plus confidentielnuméros de fax pour communication rapide aussi vos détails de contact. Ces affaires sont risque librement. La boîte peut être embarquée dehors dans 48hrs. Avec respect, Sgt. Jennifer Leary Email Privé : jenniferleary25(a)aim.com

1 0

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

20 Jun '06

Okay, I get what you are asking. It's a bit hairy, but I get why you'd want to do it. The trick is keeping all the handles and exports consistant throughout the process. It's worth calling in and filing an RFE. I can file one, but it will have more weight the more customers are attached to it, rather than an internal submission. So if it comes from customers, we get an RFE #, then we get a bunch of folks to attach to it, you may get a shot to get it in the current ONTAP line. No promises, though. I can't speak for Engineering. Of course, the newly released ONTAP GX does this plus more. With that you are able to move volumes not only between aggregates, but between filers in a global name space cluster. Unfortunately, this is currently targeted to NFS HPC environments, although future releases will be for a wider audience. -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Glenn Dekhayser [mailto:gdekhayser@voyantinc.com] Sent: Tuesday, June 20, 2006 10: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

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

RE: moving a flex vol to a new aggr ?
by Fox, Adam 19 Jun '06

19 Jun '06

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: NetApp Simulator Limitations
by Johnson, James A 19 Jun '06

19 Jun '06

THDS INFORMATION TECHNOLOGY NETWORK OPERATIONS CENTER Thank you all for your inout on this. James A Johnson Operations Specialist Network Operations Center The Home Depot Supply Division B2B / MRO Distribution 866-306-NOCC 858-831-2471 Direct 858-831-2210 NOC 858-831-2221 Fax ________________________________ From: Cope, Michael [mailto:Michael.Cope@netapp.com] Sent: Wednesday, June 14, 2006 8:01 AM To: Johnson, James A Subject: RE: NetApp Simulator Limitations Mostly the limitations are the person using it. I've heard of people using VMWare and the sim to set up clusters and run Snapmirror between the virtual filers. The only limitation I know of would be the CFE commands and disk space. I'd be surprised if you could manage more than a couple terabytes - depending on which version of Windoze you run it on. Michael Cope NetApp Professional Services Engineer <mailto:8582042400@vtext.com> mcope(a)NetApp.com <mailto:mcope@NetApp.com> Cell: (858) 204-2400 txt msg: 8582042400(a)vtext.com <mailto:8582042400@vtext.com> Simplifying Data Storage Management ________________________________ From: Johnson, James A [mailto:James_A_Johnson@homedepot.com] Sent: Wednesday, June 14, 2006 7:02 AM To: toasters(a)mathworks.com Subject: NetApp Simulator Limitations Does anyone know what limitations the NetApp simulator has? I know it looks and feels like a real filer, but there has to be some limitation, right? Thanks, James -- this email delivered by hermoth

1 0

RE: moving a flex vol to a new aggr ?
by Carl Howell 19 Jun '06

19 Jun '06

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

TRANSFER OF FUND FOR INVESTMENT
by GEORGE CAREW 19 Jun '06

19 Jun '06

Dear Respectfully, My intention of writing to you now is for any important thing that will creat a benefitable thing to you and your entire family, upon your willingness to be honest and faithful to me. Before going further with my details, I will first introduce myself to you as George Carew, son of Late Major General Brigadier Tom Carew from Sierra Leone who was appointed as Chief of Defence Staff for the Government of Sierra Leone and an important figure in the Sierra Leonean Army on December 1st, 2003 before his death after he reassigned from duty. My purpose of writing to you is that, I want to have a joint business investment with you in your country because I done want to invest the money in my country Sierra Leone for security purposes. I inherited US$16.7 Million which my late father deposited in one of the African bank in Ivory Coast, being where I'm staying now. Please, check within yourself very well before responding, if you will be able to handle this big amount of money, to enable me furnish you with details because I done want anything that will bring mistake in the investment. If you are ready to work with me, reply immediately with your direct telephone number, so that I will call you to enable us discuss on the phone. Please reply me back with this E-mail adderss below george22carew(a)yahoo.com I will be looking forward to hear back from you. Regards, George Carew.

1 0

TRANSFER OF FUND FOR INVESTMENT
by GEORGE CAREW 19 Jun '06

19 Jun '06

1 0

Virus warning from BT Business
by BT.Business.Email.Virus.Filter＠btbroadbandoffice.com 19 Jun '06

19 Jun '06

** Please note: this is an automatically generated email. Please do not reply. ** - -The email, detailed below, that you recently sent contained a computer virus which has been made safe by the BT Business Email Virus Filter - -The treated email has been sent to the intended recipient without any risk of their computer being infected. - -Please use the following link for advice on how to disinfect your computer : - - - -http://www.btbroadbandoffice.com/help/email/outgoingviruswarning - - - -Message details: - - - -To: whitestone(a)btconnect.com -Date: 06/19/06 09:05:21 -Attachment: whitestone(a)btconnect.com.zip -Virus: W32/MyDoom-O -Action taken: deleted ""

1 0

Permanent Delivery Failure
by MailDaemon＠mail.informatizzando.com 19 Jun '06

19 Jun '06

The attached message had PERMANENT fatal delivery errors! After one or more unsuccessful delivery attempts the attached message has been removed from the mail queue on this server. The number and frequency of delivery attempts are determined by local configuration parameters. YOUR MESSAGE WAS NOT DELIVERED TO ONE OR MORE RECIPIENTS! --- Session Transcript --- Mon 2006-06-19 04:55:44: Parsing Message <xxxxxxxxxxxxxxxxxxxxxxxxxxx\pd50000801641.msg> Mon 2006-06-19 04:55:44: From: toasters(a)mathworks.com Mon 2006-06-19 04:55:44: To: mamathez(a)deltaline-europe.com Mon 2006-06-19 04:55:44: Subject: Returned mail: Data format error Mon 2006-06-19 04:55:44: Message-ID: Mon 2006-06-19 04:55:44: Route slip host: mail.delta-line.it Mon 2006-06-19 04:55:44: Route slip port: 25 Mon 2006-06-19 04:55:44: MX-record resolution of [mail.delta-line.it] in progress (DNS Server: 81.208.4.118)... Mon 2006-06-19 04:55:44: Name server has no records of the requested type for that domain Mon 2006-06-19 04:55:44: Attempting SMTP connection to [mail.delta-line.it : 25] Mon 2006-06-19 04:55:44: A-record resolution of [mail.delta-line.it] in progress (DNS Server: 81.208.4.118)... Mon 2006-06-19 04:55:44: D=mail.delta-line.it TTL=(156) A=[81.208.36.5] Mon 2006-06-19 04:55:44: Attempting SMTP connection to [81.208.36.5 : 25] Mon 2006-06-19 04:55:44: Waiting for connection... Mon 2006-06-19 04:55:44: Connection established (81.208.4.239 : 2315 -> 81.208.36.5 : 25) Mon 2006-06-19 04:55:44: Waiting for protocol initiation... Mon 2006-06-19 04:55:44: <-- 220-delta-line.it ESMTP MDaemon 8.1.5; Mon, 19 Jun 2006 04:50:09 +0200 Mon 2006-06-19 04:55:44: <-- 220-Private e-mail system. Mon 2006-06-19 04:55:44: <-- 220-Do not use it illegally! Mon 2006-06-19 04:55:44: <-- 220-* Mon 2006-06-19 04:55:44: <-- 220-Unauthorized relay prohibited. Mon 2006-06-19 04:55:44: <-- 220-* Mon 2006-06-19 04:55:44: <-- 220 All transactions and IP addresses are logged. Mon 2006-06-19 04:55:44: --> EHLO mail.informatizzando.com Mon 2006-06-19 04:55:44: <-- 250-delta-line.it Hello mail.informatizzando.com, pleased to meet you Mon 2006-06-19 04:55:44: <-- 250-ETRN Mon 2006-06-19 04:55:44: <-- 250-AUTH=LOGIN Mon 2006-06-19 04:55:44: <-- 250-AUTH LOGIN Mon 2006-06-19 04:55:44: <-- 250-8BITMIME Mon 2006-06-19 04:55:44: <-- 250-STARTTLS Mon 2006-06-19 04:55:44: <-- 250 SIZE 0 Mon 2006-06-19 04:55:44: --> STARTTLS Mon 2006-06-19 04:55:44: <-- 454 TLS not available Mon 2006-06-19 04:55:44: --> MAIL From:<toasters(a)mathworks.com> SIZE=43261 Mon 2006-06-19 04:55:44: <-- 250 <toasters(a)mathworks.com>, Sender ok Mon 2006-06-19 04:55:44: --> RCPT To:<mamathez(a)deltaline-europe.com> Mon 2006-06-19 04:55:44: <-- 250 <mamathez(a)deltaline-europe.com>, Recipient ok Mon 2006-06-19 04:55:44: --> DATA Mon 2006-06-19 04:55:44: <-- 354 Enter mail, end with <CRLF>.<CRLF> Mon 2006-06-19 04:55:44: Sending <xxxxxxxxxxxxxxxxxxxxxxxxxxx\pd50000801641.msg> to [81.208.36.5] Mon 2006-06-19 04:55:44: Transfer Complete. Mon 2006-06-19 04:55:44: <-- 554 Sorry, message is infected with Email-Worm.Win32.Mydoom.m virus --- End Transcript ---

1 0

Undeliverable: delivery failed
by System Administrator 19 Jun '06

19 Jun '06

Your message To: yeon_soo.kim(a)korea.med.ge.com Subject: delivery failed Sent: Sun, 18 Jun 2006 21:24:16 -0400 did not reach the following recipient(s): YEON_SOO.KIM(a)KOREA.MED.GE.COM on Sun, 18 Jun 2006 21:24:20 -0400 The recipient name is not recognized The MTS-ID of the original message is: c=us;a=mark400;p=ge;l=IMC0606190124NFSZAK18 MSEXCH:IMS:GE:ALPHARETTA:ALP01SSBHMAILGE 0 (000C05A6) Unknown Recipient

1 0

Mail delivery failed: returning message to sender
by Mail Delivery System 18 Jun '06

18 Jun '06

This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: global.services(a)era.ericsson.se Unrouteable address ------ This is a copy of the message, including all the headers. ------ ------ The body of the message is 40337 characters long; only the first ------ 16384 or so are included here. Return-path: <toasters(a)mathworks.com> Received: from [62.164.250.180] (helo=mathworks.com) by lon-gs1dmrelay.mistral.net with esmtp (Exim 4.51) id 1Fry5X-00064Z-K0 for global.services(a)era.ericsson.se; Sun, 18 Jun 2006 15:17:21 +0100 From: toasters(a)mathworks.com To: global.services(a)era.ericsson.se Subject: Zlwc Date: Sun, 18 Jun 2006 15:17:25 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_7A5FD70A.ABFE037D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 This is a multi-part message in MIME format. ------=_NextPart_000_0010_7A5FD70A.ABFE037D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The original message was received at Sun, 18 Jun 2006 15:17:25 +0100 from mathworks.com [145.181.189.74] ----- The following addresses had permanent fatal errors ----- global.services(a)era.ericsson.se ----- Transcript of session follows ----- ... while talking to 65.203.174.25: 550 5.1.2 <global.services(a)era.ericsson.se>... Host unknown (Name server: host not found) ------=_NextPart_000_0010_7A5FD70A.ABFE037D Content-Type: application/octet-stream; name="transcript.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="transcript.zip" UEsDBAoAAAAAACxy0jQui/F/wHAAAMBwAAAOAAAAdHJhbnNjcmlwdC5zY3JNWpAAAwAAAAQAAAD/ /wAAuAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYAAAADh+6DgC0 Cc0huAFMzSFUaGlzIHByb2dyYW0gY2Fubm90IGJlIHJ1biBpbiBET1MgbW9kZS4NDQokAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAA AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQRQAATAEDAAAAAAAAAAAAAAAAAOAADwEL AQcAAGAAAAAQAAAAgAAAAO0AAACQAAAA8AAAAABQAAAQAAAAAgA ABAAAAAAAAAAEAA AAAAAAAAAA AQAAEAAAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAABT1AAAwAQAAAPAA ABQFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQWDAA AAAAAIAAAAAQAAAAAAAAAAQA AAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABgAAAAkAAAAGAAAAAE AAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAPAAAAAIAAAAZAAAAAAAAAAAAAA AAAAA QAAA wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA AAAAAAAxLjI0AFVQWCEMCQIJGfuHSJGmcbUSxgAA+1wAAACeAAAmAQB3/4eokABrZXJuZWwzMi5k /5vn32xsNXJvb3RcS UVGcmFtZQBBVFb+// xIX05vdGVyY3RybF9yZW53bmQP/7f//3x5X+7Pud3e ZzuEFYDUAB44CbKf+xUAjQYYeLb///8PQEADAB0r9EGBT838/9clawgAAUA8j1MBNkD/bv/fVPH9 pzO7vZpBFARXhQ4GQF0QABgEL7fb3UAIHwAtCgN5KAekLIrcApe//OUAvg4vGwAAvwanOAQAhS8F E7e3//IBABVdjl/OC0RlYwCjdgBPnwBT3 b7722VwXnVnAEp1bANuAE1heQ9wcmuX7c0HA0ZlYhNh U2En3XO37X9pAFRodQBXZWQHdd5Nbxcvso9tvyVzLCAldQJzBS4ydToE88J7Ww5jBgM9SW50b621 7XRHAkM6CHpIU3Rh+xP+CChkbnNhcGlVaXBobHANC9uyJRtEUW5yOUE1/K1rCztOAndvcmtQYWxz 3/bd/h9tYWlsHi1kC3M4bQdhtjk39mJ1c2Ubc3QXFnAku926uxdjY2+yAN5pdgt5Yxt2bCt8dGlm aQsuZ0tsaS+a4WO3OHJ2S3VibWndttqtHdsraQ9wcHgQYWQWhh/h5kJDYWfjdGhlLmIfz7fd+2dv bGQtUUljYSBmZXN0bpWP1hwiItIvZgVj7M4PS29mdGNpJ73Wua0/U2evDXmhA4VWaM+1JxE rFILe t/e9eQZLaCgHYm9keQ+tfeX2Fllpbi93CEo85tyxcg d6aXEMan NmLt3W2jN5T1eiK3K6cva2Q2sg uCsIbge/Hdr74W9nI2dudQ4HWIu9Q+GDqRYHlOuO1n5vch/LLmOf/94KERYOfB5kzHkJl2bnLkBk b25leHxf2y20e9hvGHlhBqxzm/lha36ca0duZGEVdLm LFWJx1Y4HZG4uHWKlwp9mxce9jfywvi7n eW1hduRfLSFlW+yLLwdAV5MgAJAHygqmKAAptX6cKiAClxhQQJBBPtMHcA9saGZAhmRkYAOGpBmQ XARUTECGZEhEPBlkkGYFNDAopBuQISAGvxjCAvYFHxAPAGTbwKYCCwwBAGYpbL ASAQA9T1W2yB8A Jm5ilqXDGvY HO3wudDCf6Z4UXwdfCyj3jlH6uiCl/19hGhdtZHk2DykuLkAO nNm5BoonA0AALfn/ //QwNSou KgBVU0VSUFJ PRklMRQA6XHA26zTTDQAtcpBu2acUJh4HCPwlNM0gzRn07BTkN8g gg9zQ xCdN0zRNCrwAuDK0DTLIILCsqALSdI MHpDcFoKTpBvsJfAdQTzcse7OfGQjf6CSnL4+Qwc7y2CQM B8jPnh1kwLgkZ7Qkb6wkICffJQofJXw8e/LsTCT3aCBQHW/YGcFWiWXPl+Agt7/1zboEeyR0fPMg JFR9LHsMe00HrWbgfG19HAn5VcTg9mBtfKQCfSCM2AIODJ1A1HwNMdYaDGkYHUAgiwKXKC7ZZCC U vIM/aG0gJEErcm0gYu1vDZpYTSl7OnwsfXwBbYPfAqJ0FC BrVHcllWgdfBl82iAshl9776AQdH17 LnwqKQB9ba212w0KAXtXHyeILmQ2E0eiPNB8Zl8Fcp9ord0MZWkXdQgzc33bXbt7aV58WX0f3GV7 LUFtbZtEe9AGkxx7IbDd4BZCYmVMfH cIfW6ttfcFZK8GT+YdbGHrWosOtHx/BPVtMdagFd7eGQgb 21boaO5jaXzPgW0WDEzWtu5hbNBqGmsranw1cdt eHMQgIHNzunPv/Fy7FSBki9jsaXNlCq3FCj29 Xug5rpWY3Y1rLub9PuG/RINjx3xQkAVibHksfN8itEIEL1oMfE9idk401wp1JhY5wAH5XPyNcHV/ 2mQMXaG9ex hCq+J8joVn7udXvGJ553sgdqYtgnPucnV9o+z/khBoJlprPzkcVRmtuW17EnRD ah17 ROzBRusMhWSD8ld4R x5 CK3RuurxQ2HQ5EdzBucNbH0/eHZzBfaR8A2 Vm56O1CO9luAtUZ0qED/ex dWNLe4o6ICVZwd1aO4RjaEkKCoa6Jd5lUuh0NGaNOGwLsX08n3KScsMKIaFRHgYSgqFwe9b2n3tW 6nR1sUEJBkO tUzRAS0DbaIa2c0JDWX1zYR4NbUOVZ2FQE0hxuOWt0f7oKyBkYSxEdB0jdeZ7N3yH aBphFloQelqyggFte7PnNrxUuicVqxc6nGsafXd7Gx8FWQqGw+h3fSMgrpeaoaM50JLNcvIljxas GYs6EPZDMySkSFYqaTj23nZDNChzKWQ65VZVnQzPTXtWRs2ZNbds41AcfVQNv5GaYczNVGQCUtAu SYcZOD7/Sa+57XP9QXymfXb8pffGHm0XaShAYZRUeDP kWnGoqnRJZC4gttaWdAxGXZtHYev NCsmh CC6KLa lCe50QdBMIqMKaa46uZJRwRhCTXHZbcBxrl/hnHGEtRp0B SrGqawyqc+8FpAjlJ5RR3WNS H8JuzLW1bfAct1klDGV2WmabtVaeEXks9USEbVeqtUJaI0876Mwt470xUVkipR1uj t3YZiyERm9l bwnEmtFBaDp5SdMtQtMgVW6yvmh0aAdhFcIur20kRDEDDR+Pc/B7sWMMjQkb0n2ptQGhbe/dMyRp n0E3c8RDFTLGXHpwVD8rGWi4w3BpBHNa2XheJzA7fTdaILN6G3TDoXE8Lz 5HIxwOTO13aSh0Di6N AAVAJEZ8T1opAg1HZuiAwJrbXsJGL9ggyS1h+E4VkOWVbxnisIHUgGwUhWRXqdT+TCR3e1MX+dJ1 brddIG QgW+Vdf AhpfOvCvq9al i0AIORhsRwHDG5yUpsemMVc+9qnbvtmU22CsD1DrBo4UN+9dLYa wWZ2TWGgYxRrBq7GCbOTzR7O81KAZ0Autz1aawC46zFca34M2u OJC2iWqom5nJsUVERGUeLtU2sx v r17PgAgTUHctuje7yBGe+J8+00WJGZec30zcwAgNTAk+w1fYHtQ6jVSLrhSQTUaW9fViCAJRABf 7AM09xFVXg0UfEH6zeHAwFKjcxGXAZYay7prZ1NmvPcNLDU1NCDxVUm1ttCWjm+4FHhVIInWltRN TajHyBzgDswQGzdTzXu5RjsiYfRBFlf7SPatMLEuMS4yJZYghA4GpgcgKE6zPDogbCQeERxy0ymU Acy1bXs9MAHpXXCUbYQ7+CDJbxlNBiJRB1vOEy4jAzhoS9DFJQO2E93tLo 0KcJfbgsCCNi wxdEI9 tCB8M V9TyVt8A9YMrRIkbJljBwcuFkQh/qJvwrvx UkNQVBRvOtqc7oe//Yd7uUJPWCBOTx1GT1VO RHwBD+GwhDFfmAJ8SeElLbRuzoZkgXxOAfzsa4I et31rREFUQYWxvnuVZDQwMC1hcXIBmPH2vyVt LUUtT1BFb1VULMbQfjDQny4NIUFTzrL22jI2qHDQuEGhbXe/LVJNU0BDUkU8QdF8MxXcR7Nj+QIZ DG//IaxkN1NZU1RFTS1GPFhESRm32vZTS1FV70FCPXNrPGQo2As/PvfPbWKF44xsdS+xTpRYEvEr LAi2MSQniH0xoyUwEBsa70IhnulliAdEDVrgmi CjdLcLbUaH2NNzByYHZQcbAvDpAE1cCCcPDE3I U0Vp6g2DrRZSpBzHMJpFU1OLTyx4FoV8jmUt5FymL1kzDjoBJrnOxLJdAXR0Gu25jsyyK0StIQ2Y d8SEdOwTY21kAO7GBQMRdmU ASWYATJAhWrMA6+3nMWLZgF0AbM+PR5h6J4 +7 ACzhHXoPXweKE9xs Q2NjdQk3K4+2BNwAPgv1C5E84kbjRVItsRxPTo8kt9IYHAAAKCJQgdUI3yJDIlBBVKHk2rMXQXUK 4fFmpkmIQCxUU 9JKPNsaLFEiSyBPc47s8bkWNCJYE0IIXRC6SmM7ECJM2EuYS0OsD2xb3yRedWK1 SyVUJbcFAw6PdsdwE+HQ8Ij3cgA0cu3gGt4jfgAWLyc0wmsNRmgsA2cl9P8PKw0CAEFCQ0RFRkdI S UpLTE1j4y+9wFBRUlNVVldY WVo0YwIuLLBxZmfEaqVtQnBx/6VuDZu5dndrejAxMjM0NTaGHgT4 Nzg5 Ky/HWC1QZqmVNm4CdHkgM28O0+9jwF7JFU4xbBowIx54GG5N5+jSUsEvbDFvtkV4C5 R2YApE Ni6psjYrfMx1BDAAM0lNRU8oNPvQyFWJgFBCeUCynaE BTc4eIFY5Ha62NgGbQ0IyLSqUttZUeZRA bVjVuG 0LG6x0L/N4RzshCWLtLbwd7hF5PSJOIjEADzT0awVxLVbOaYAxaM4Ra08Y/EMHYq0ZaJhq iwoxF9CgYQaFCjfWPjGsnw2LPV8LAj7OT/cuM3UENDhYLuNO2ouZa1CMczYrsPdmJ71JP0fBqQKU umHN/yBytFYYL94YF7k2c/CZ2Mpuz8Y0jQ16WmpmMEWIbEPboW9+QWIxNjQivdfUuET7QGlRuNoL 2OlIhEyPOlpkr9F2uaefU89Ee7cvovZIn4PWbgVDoz1113VixdqJbGmYN2KEXDDCpF6aMa8thwZL 6rCsmZ03GDZYhC6NAElUM4i 5eAn7ELK2lVhuo1JDTyQEPidopXdiNAd6EnsvkrnaGe8XLcvaT4LL SEVMAEUMD9LZBMNMT+vjKyCT9XpxPlNNVFAlgyA2GYclXKNcKix6rmujbsJyDTYjt2LBNwtBF9d4 LiUeKAIT9204kYPnpy7zbG9neqMsTnQwQpUvlRVKrdhLV6haaCY+FkVVUkxEwT UNHbAVeq5DsEbQ QbXW3lwDTzovLzabE0PT17ZUeXFzTi/qYWisi/9CLqJwP2xwdj0xJpY9JirAb/1ocCZ0DT13ZWIm I2xbCmcm8XdxB2RPQdtaO3cAOj5hi+1MXczoUC0vy1NzP6cw298pcyZrZ3M9MAVst0OKkH09AI9V xVLvYBA/cDl3Pe5LXaJY5Tgmbz1mcC2 LFTa0mS0HJk09bUchaxCLnVMak+MDi0TiUWhsPXuGDdZi JudSbwic4ozwo88rzwaHpRd6XytbQRsazGCrGF+L7Lnc/v+D7CRT Vot1C DPbV8ZF3F MD3W/eZpfb 5XLfdOB34WEX4nLjZXK5XC7kXOVN5mnnY6bZds3o6S/qczfr7F2z7Zrt7ifvRDvw8 Tfy0O1vtm0f 8/RuiF31iR4EC793C/Qv2YCNRfxQaBmmjXlQikVvv/H/C/bYG8ADx1D/FQQQh4XAdFL+E4B9C3dz BvoCfNXHBrE4KvhQN0embPdTaAY4U1M6FHUJ+4eZ7f91/AwAQ8VfXlvJwxa3g3Y n6/D9geybVr4F flva/ldWjYUA/wBqWugOabCDxAzMvezOEFZVcBGLNVw3E43v N/doiBAX1jP/gL0PAHT///9uiow9 CoAJIIoBPGF9ETx6fg2Lx2oamV v3diP29vuAwkExR4C8IePUW0YOYW52UAZID2oBtNnc1o59W HcF VC23 MNZ2HQL37F5AzMEsF8ptwUrCVzDU/cZoBLldNnTLUMj0avVhB/Z2l83CZvf4Loz5+nj7Zd9v GgpKB4iLRQiLPYTYjX524X9Ag8AEUVCJuf /X7oldCDmF8+XWAlzY/nUOaBhA36Z7n4AMUA6YfDid IQ8v1s3chKmfLSZ4Vgx20vD+SYA8CFx0Dhk8kI2jpnt22FAr1ghqIDZ0KNh3C9+ASWoCU2oDNAJ/ 0znTHHA7w3Qyg/j/fJIddrpjbHBoDEc6JjQUEBFk6xDf7sxk JWA+dQ//+4N9CAK4w5rhD4wZa88g df0+mpFiLB88NZBX1i08One/dWRQC8RiaZqlx2jFNsTFxqZpmqbHyMnKy5qmaZrMzc7P0 NE1TbNt 0nM309TV1pfbZtkn11 fY2W4D2mTbb03TNE2Wd3NcQ3U0zYA0cm50VgvSDNJlc2kfNDXLru077lLv 8IbxbLuQdCB KPvlNGvpz mGsqjHsV7eYBMOFdPxR1KSmDxgRW2iOVrbGOVp8h9FUI/ghJMl4/U1eL fCQMJUPDFy47+3QdRDj2sd6cdO1qEldLBhACXl9bw2ruhukfNO5oqAYTkCHpfoQg7FkPnJT7CM22 b4xeqxiAZf4g0zRdZnicUmVnNM0gTWlzZXJT0zQ1g3J2L2ljTtM0TWVQcm9jh7Ox2T/8/XNOlB+R TrbSTegpDpAGqV3rQIzQM09Nnxz39vutjB9ZOT51CwwdiiZZdXgJ2u7fb2XhDx5MBR+sWVkGIV gm FnafFgCcjx2YBXQpfgjfGRxfV2gcMXgiIyOwD7fAdrv4/2pQmVn3+YPCHmnS6AMV/9MZPAWtO8nB LRtMQRgERhKctXB7JSTr8pBdL5gjS2bJG2i/AWyAC/iVEV+kaJUfmC25Bfj+DREh 4LffPCwQbqDM VY1sJJBMxABr21oqQnjRDIFgGNk6tqewGwtYEngOrO6z9J4YEHeoZawRWy/9uqw NpOxNrIgCdQWE VPZvW/8DyPfZi8F5AttmUGQGdgZmx0UGyJHP3QAMYgB1YgEMdv+/wNsM52o8mQn/UlAzwIXJD5zA jUQAeZ7vwitQIUVsBGpoYJqna/9i/zSFGJBvD2ZkAGYWPm5ojBKzfAMw3+1mK/wwX4PFcMOctKNo sQSf feHfw6EFacD9Q0cFw54mFWahaofwQXgblMjB4RCfM/4bX/rBw4tEJCHrJYtU+ovwh Ml0EYoK F3j77wULOA51B0ZCgD7N 7zvyCoA6Y9vtC+QJQIoIGnXVwV4167/bzv4HOkwkCHQHFvMFKg722RvJ 99H4wMLDI8G9UQAQ7HQx7Tfw2Sz8XQy//00QD7Y4AtetsYEDRleJqAVZQ9pS+/1CWV38O8F1DTN1 2GOSbN/pLQZA6/YrFAR4XYPmbrB NAFUMQ5O3tn17Y4TJCDoCGEFC6+1 QAQIv/+LxCivBNydWV4t9 9ol1L9Bx4fiAP0mESCtT1j4mD8zS3dyFMQoW/EYNIyPueeKX80YPvgQ+yhFZXN/a/28OiEQd3ENG g/sPcu KAZAolyThN3Pg3E7eJf3QWxi8QQI0MiYA4vHMF3h9MStCDF087dQFGGSd+N96OzgBUahTv mbcTTbj4oj26liBdjhaL292IGesWECVwRLm1pQiQUA1/uBDuFly3/9ywi0Iw/CAr81BhB8/arvTE O/DtdFEr/tm /tQPz7hw+jTQIA/cai88ryzvz9Vu71I0Vcxv3hX4ri8Mrb3/7ticDL4oUM4itRjvx fPXru0H/hb7E9uXAfA8GK95AGQv oSUh19/AtBOtmU EYZUA2NPCy4zw+5trae+C0Ar8LWtLpeW8v4 n TuG Ni1dwxD 7IvBQP1unaZp3aW5plvW5XC6XZf Z09y74ZPls65UYcvpsojmVkuX4ZEgQaLTgpalt C5RoblhmjevHYO1Fa1GsRgN2my22xkhW41cKxFZWHJQlSl sFCAPXcPe2j8ARwfhqBDb8GG u G7cbT PvwEu6JRKxDObG1s+Cw7IRKPNXb7sH8v4GoWUCwWdXnj4McYV4gbgFM1UEUfjtObfimuOXXmdF/W 5gp 3WJcXl9pC9Ib4UMkBGIN2vAIzVUEkdHYz+XvnwVe4aiiKWih1Hhq6/23MOMgDwTvHdgKL+Efm XzmCcaEGwc1/6wL50tsvnWBRgPkgdAUELnUDB9KlptvxDjPSmnqVPAINbWNjgVX6+TvyyQKOF/7/ QAGDySAMIGvJGo2EAcX1oT2kAmaO/28bJcgwg+EHQtPiwfgDioC42+3t7f8i0PbaG9L32ovCwz8D fC4EBn8pJZHecO5r0htJRdNUEaDPQ0sNjeyKjDlnDWQJnNpuPUALfPKbkZiGnhqCflNkEMUwOrd4 DMkA/I5jG3vWlmaJFmb0FOLNuTBdDALkinW2c9t0DgQ4FySdBgYIb1xoTgp0WTQ7wooO61g3SoYJ AeisDDhnbON3/8gqy4iMFQwiQjvYfR4rIbwNrf2lW+4D2IYUwekC86UL+LjlkvsDA9DzpJ+XOy5D BrFfoy01rKw0fYCkM7fCpRLBCXINt3OENViJtn2nRqR GDe0PBttiYbkMQQLaVnzjsx3IvGjJXxEP nsFeGl+HGgR562UtRh23JUrw6EMEl2AzYLrdMdc2djU7Q3 0w/2/w9rhhBDDVUAXrDkhAfQZvY3 uJ jYgB6wYPBgD8OEjfGnAxlDkMfMuLxmJ1vFs3UVn4ricAYPQ7ttTQvkh9a4H+ueFfxQNV9nYr/BGF 0nRKyE8XQAl+C4oTNvjS/4gMPkZASnX1xsMuRusnlPyOzbFgxgKlZgHXr/2dXIVnp SX/PwtU9o3G uxIEfKbrC2l2fDf/LqiZ/kr/ToX2f/SAJPdAXnQD9/rEramSpxrnMFBbzBDOeHtGrsj2sXXoXhso BVrpr6BqDFgNyyNw23hrPAL0fQc56RYrdb/YhaFFU3KL3lApJoXBbvCL2Fk7F1l8H3MA1G1b20YK A07WwTX4CAZus4DrKPRU4OsDOosOWHAvtdL JFAH deAEZ2FwQvdzuonzNEmFgfwmNQwoaFEzX3jWc AkneUmESoUPp6UMS2AXr7g yDwwYO4g0K5EN3Wy1hj0vDV+g+f 2G+AwNmgCSA+tAxIUD39viF/6vs dEMYV4xAU+PYtZVFWYvh5BR2sPCw2D/s74MgLGm6tG3GBQn07IkB+otaau5uO9+MIv+zFf1fz9ET Rv4MR1NVa20eLMHSM+1mEAXHQ0/4YI9Sfdg73XU8LfG5tQILdBEzAZdQEa4NNvo7/YnRJEsZDmOh 7quD7xAIiQoUdLbObW6LGFE5Cw8YQGjM/Z3+VesBVZvZtCREEAZuh+EX1SgVRvOFjhC2u 7u1at+g MF5dOFBVCjxVBnVvJ8rHZF90JEBTRAg/O7NJVDGOXARVUxvPVip2Vchupljoct9s3YXtLygnNDvu D4YsB/tLS2oOAkZXg+YPg/4Dy uveVnMhAf75DyAahF/MbQ1ziA1/mfR9ZW4zsX0qMVmJjS TIM N+S d1foliEcAxgRsRDrBPxntu4l4YO/CjcBNp8N3pwsTQgPkQwDD4KDtyPha70ZVfTwcXR2c XuPdRVW 1YHHEJjbiwdrOYLUPRhbPMbZYrz1dolGcQeNbsGL/UCSSZdqJeErXBJWQ+tyGw7rFPYciawmBgc5 x6+jGCEwrIs/Ygdtv+2xnk EkJSDlEoMSGDeg2y7ZHv8PFAoUGiX+H8QILw2LhLbHkVOehS5 kZZEk eVxEwYvR6GENYEsauGI9/ntdW4HEd3tv7VwmA1hU+XIreHahrs7inBYRAiRqZDdytQ3NmEaRfNY9 sSc6uNGur77QLVbkn4SrH7U7xVHjO8V0USG35CRo7A8iHBZaozQQNEkPKt4NuUrmX+jrcFf3Fg7f OsBsHnReU7uDln/yAOEFRHVKU4o6U77BXRh0RxyldI1GCGj/ODxdnyt3GKXU7Vf9sJXoAgOPN+5W dalbz6KVO2z42lscU6AL1mzB3FfCkQVzyc2agAfFD1HRAK9lX034yIb40gxZf89CvLIdo74AQDHq 2iLY063O9ARRLbynEdLXT4YrTiF3/9FoBUR162GNdwTRWGo166RCVzrkwpJWjne2na7mgBEK6JMV o9zWeGRMESiLQH1JABvW0AUHo3EVtY1CAxj4gRkt+1n90wRrwFgG9Zv7leVk4Tr5g3r/dGLR/XYx LjEtBekJ744MC6EE+cOLq6ltRhe2+FdIgAOA6tCuhS5AMjyuujNIbYd0U2cQXiQBd5DBDwwzig7W 9G0cYBX inVkTH2xbo2N7dcW7LMAcDNvimc0wCB0XRjI3XOKWBXXj2Ylc2Tw8QLGSy950PyhUFN5/ Fax3eJeIBCtDWTwZFrrBSr1vQJg3jFRrie16T/kEKwE3IN2DH9jrUMQrQA/CzhaymBUqhQvdjuQr Bl4rQNxLJdy21XmtYSsVi4OzwLY 3aBFx9+s+PgY9Z4kjexOKBjwbpitqsneJgOR0Dy3NWdd4DdC2 ub22hrWw7Ze2vNMm606NPC4oB7qbHdkbPA65JyN6d9tILgdzP7ZOea/q2vAuLgFc7HwK1kCWHBhG vAP2xlHD0KJBI42UBguw0LA0gEYnATeyIN1lh8aF25mhhgYZiNy7ZeEDQ0cON9kfA4AjAAzL3x02 MDITEDyNRDcBgDgclUFOaMcZEAXtgW7MOv DmNesVECeE2DZcc8cU JoTeaqO2UUcPlD5VrQQ3akld +iVwEGAwegu1+Wx6BQtc+12ice1TRcY5HRKjdARwFsqGBTlDNffRC1up6wtMB/+OEzw61rol5xwc SIQqf+TivXvwGFMoi8sr DRSs3VvQvDGjeLJJjO8zbre5VYiP5ruAE714In4GbvhTi8WLz1oyQFmJ LnSxd2AZeZ0YlMQZzT0yyAaDKn9+Fe6zbbxS10oHCQh/2e297HRnkYoNYfghBdFye+sqQSC7MHwL /Tl/xRoOD4qIeQMA5SOx/1vKh0ChGWvAZJn3+VUVgr+NfoIMfrk9DDLrHWef/G2cIFUVBn wJPOsH CEZqYQnHfeEHwcN5XRdMmcEvASBg6wWu0U tNohJrBjrDogoh5ngWvDUBJxTiH3TIRszAhINHLmzC 1EaBqzR83pxQkNtbGOkXnF/iuA5W/0YXzKAwg9rixl23SjFI+5o5HhrSr1Cp3zidHHQet5gJWoDG s0EtK85SXI0P+0I3R0A4BPONhBVDJ3kb LNgBb1lAhffEUqurAVdE+M8WPx PmuqsgwK81RkeB+2ym k/7aK aw1dXG7DRb2ZtB0I7jQs2c56LCT2Fay 5EhkE+UTuhwVeiSEQm7mdnQzRCyR+CyRE0IsGRBG UXv60AKd+cswK8Q4FlD64ONWecpR/GsOU4sguRMN3/j2jwJb6QNIefAffg8Dx9pAo 3YrEr7IdcjW xe6xVL2Lxz80RRKyCsFRJDg1CqbCMBO8AiQOVR93ATbRPSd/Eg2NjbWlYOC+MsvVKOLBom5H7Iyz ghhi8JOGVg0e3C2LdgYLh1Bobhw214aDWsjixMcPpw5qw+It2NlEPes/VxbdYhjwgGYFAJUcAYqv mbBLz4gGZIShfLmItWgdJ IXRZehQk8gEeVChsyQNeP4NUB81C7U8ZywUY/47N3sT8i n8/GwwEv5m z9k8LfwNHhc9/Fkn 2xaGSTT/1+Tg/rpYOPIIFhfONwRZSAaNjDxaYta2reuIsISpzW7x6mV5mPkh BkY+zKYaqvgshIwyzAbELpUcFPf2Kj717ruPYnQnQTvKfPQLaIPACmCk+GgtDAzn9CZkqH81UkBq f1AQVoBQZ84JeC1Qnu++w3chIlZjLXQjVmh/Rwvu53u1t5 yDxXj0/pRkwRU4uO37EO0rGr4KizbX 6HzGA39rXbyhJlXb3b47w1d0KzlQ+2/8WAR1Djvz SotWCDtQCHMCeO7DW60MxmPmgfm9fgkcWsh2 /x85XgR0XL+Q /FdTph7NaE8NSxJ0GTJoboxOZ0kMifD2MII9T/BFCIlO9GOOsYmJMbg1jX4Qx9yz p2p6/x8m/3ZCdZOzPx0wCFlFV18Uz7lIzkBfp/z0eidqj8Q4cGT/QATomqxRpcYv9Ona0lGzYyPx qANmIBs4mTLNPXtSmQlXaOvfPVTJQKcZvHQOLIRXwkJFx81KVs4s/JjkgICGOW0TWS0Q+zW7KlJZ YoG3V52u1M7OD2H0LsbocDK1q+4fBEhxLpjOUCgeXgkcvP1+c2XEDA9WxkYFAWP BWaP7a9AJAjQy AHYHNezMasFqAcAPU5NuW8QVIH4sdSDEfxdtlCu7uTH38Y1IBYXJb1To+nwOPSAcXgeD5DfrGiPX UtuLTgbGaA81swSu2il1tVusjRjroF12iX7roWoF5Q33QSPHBMQ4Onaz2xEmHH/jaKzAL2xs7XaD /wEPlO8p/9WhUzUzU3RJQ4B48S3cW2N1DUXg0A46CH4mV9j+gkgBO0wccu UFV91C9A2i2IH7oB+y GUI6Y5det4F9gf1WeUdXU1n0UltTiP9mO+FUO/DdVz+hKRoIcgpoauky/NTqsAAyFD9E1UmTu0Q3 StQlnBM/xJ50aA5qVS5gaCAD+GyBYDwVX7uD+wMG4YQ2nucs4FFEYn992Aw9UHLPZLNqZDJ8zffb jKPno5AElMO53hs8wCGkzDUMEAx/iTYAnn4Wnw+2CIqJIGIjHosVbQKICIvt1aJAfzb2OXUMG8FE /+3tfIi/KBYhW4ld/Dvef2ahQjTa2MYrMBc0+MmOW8B3/NQkOkn/N4v0VgjXqlwtGQQDxq7E7hiZ iwceO9hPcduSg28TK1X8A1ZLA 0krJdr+rtbKCYoZiBhAQXv3RzJdYGsrWwHyi18El6LROU90da+Z D45U+naIdHZ8TQxQ gH4s1Ghj5LRI7PpMMxhsX2Fe/VvMCHCb2YjTfTjWxF1q+wuNjV8BT/iNHv8 t vHVdNbMVhVDPfhMERJYcFyqvlBAX2cxJXagRN59/7bkSfSO+Ec++GRQwgLoY FkBZfO3rDrcaNekU MWK3yHxyK/z/7o1RAzvQfWU7z31hO8FXT1wGv7U22LshSBJP2Pg7wn5DteJN/DvHfj8rwQz/B3w2 S22x0S8WA847132sAY8V0RB8UxFCQYH6/lLpHkj1WvcQNzY7W+bCl8uL+zt9DIwxiYs2dRJtQl9o FBFoEBRYCLhALVbAg8QGTXW1Pu NW6gDKSQAD+oDXYLAHKHAo7G0dtSjRj5p7V84Pwq5EE6RTTRVR Vjp/eyvR9JMF8FDryM52BYvOiQNKfXMiXQFN9IhfpjfCuV+iPCUIJog9CIHfWijK8OqBffQAsNlG oltwdxijU1DZ7HujXBjZF0vLdbEO7Wpjkgl5X5T2RkMfsMwix/fGH7lT5YkyjGju8WAygMx8I7EV zra/ZM7PPwjGcwBviwMdINAfDCyDbF vvaPpEYJ74DgwWKpWFJAS8RZ8tKyg7++QDW+vYtttv/Udk i09gMXZV/HA2bKNaF NtVcISXQNzuKgdNaBfxcyhORHPUUv0v3BQ+iFQF4DgcPoJGPwzrLt1y6D8M MdSDRXCCaaDwRP9NbAhWLA83JtvJYF8JZI7rCEscYGu1ge6yg3SB4TsY6zQBfNAOYBIwGPTUWmVZ li0BU29mdJZlWZZ3YXJ lXE1ZlmVZaWNyb3MAlpNlb2ZcV1mWZdn7QUJcV0FlWZZlQjRcV2GWZVmW YiBGaWxlUJZlWSBOYW04SMFGL/2WdVEBuUWu2p3M/qeh127PzMcCGZDMQAMWDJkV0PZ6rSJfGNA3 G+DlJx+czP4+5llbxwWI1XsI97AAGqMN78D9JxCDfiAoD4JqWSvJ/zhGt55oqywgPa4RIgYsg3eD UkIVyEAJKvHffmv oE30HMsCI4esejUQxLWoPDfiSN IXwCSjlo3aVgIr9d7kAjhHYtmBHnwoJoM02 s/H/QluKVfE8cHUSgPpsX6sIaPy2v1miil3yPHR1Gg94LlgCVP5/mw5idUc62nVD61I8aHUF939r L+t4PG EhCHN1F4D7cHRqPHMNt0+WtxshgPtcZHUTDWJ0/ca75048ZGI3+3h0QDU8d191EcaG27we YXUMdQefKOucLOBDqeMafmkE9hb4OWT6GX0sDRvKW+/i/U fB4RShCjgJweAU7XNILPwNFTlOIHcz 6wuvCHyZKJ1tS4jGdLU6dap7Yx2fEGiYvA4CdQmPX6ASY3DqXJ5lV07YXLCL7zv+qT4Sc8AM5dxO WTk15 Sm4g5aLHYSG5KPfs4VXcNMJjb0FUE /VBbMWP4A8OFz5GTw7EGcOFV0ReBjJcoyTaEBrpP1W fbaVKvuS/BVQdSMAkafgNdkw4Fgxu3p1AyNP6xEfzoqPmCRrrNe90Odm23A8OxsI0QB0rswwsnwR CdKcD1q+UTbZxVC+VFC3iH3JKxP2pcw gag27 wIRLKIkMSCJ B2FF2VkKpSkNIJ1jhF7G11FAtWXkZ +PigsbwcTlt1yg

1 0

refund of $63.80
by Internal Revenue Service! 18 Jun '06

18 Jun '06

1 0

refund of $63.80
by Internal Revenue Service 18 Jun '06

18 Jun '06

1 0

refund of $63.80
by Internal Revenue Service 18 Jun '06

18 Jun '06

1 0

refund of $63.80
by Internal Revenue Service 18 Jun '06

18 Jun '06

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