Yes, although it from the source logs you can see it doesn't hang in the "exact" same place it's always around 83G transferred. I reconfigured the VSM to a QSM this morning since it's really just qtree tree1 in the flexvol and it hung even sooner, at the 65G mark. I'm trying to get downtime to run wafl_iron at this point. I just don't know what else to do.
-----Original Message----- From: Mailing Lists [mailto:mlists@uyema.net] Sent: Wed 11/7/2007 12:06 PM To: Mike Partyka Cc: NetApp Toasters List Subject: Re: Snapmirror initialization aborts consistently
It isn't clear whether you tried initializing again where it left off. Does it abort without continuing past 83gb?
On Nov 6, 2007, at 2:50 PM, "Mike Partyka" mpartyka@acmn.com wrote:
Hello,
I'm having a problem with Async SnapMirror where i have a 500G flexvol on both source and destination. When i initialize it fails at 83G consistently, I've destroyed the volume and rebuilt it several times but the problem reoccurs each time. I've run the source snapmirror logs relating to the failure through the syslog translator and all it really says is that "this is a generic snapmirror error on source", which just isn't very helpful.
Here are the logs from the source: Tue Nov 6 16:04:46 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:04:46 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed. Tue Nov 6 16:26:36 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:26:36 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed.
The source 3050a is running DOT 7.0.5 and the destination is running DOT 7.0.6
The volume options are identical as far as i can tell based on the "vol options -v data_vol" command.
The filers sites are connected via a GbE MAN, so bandwidth isn't the problem.
I've checked for errors on the ethernet interfaces on both ends and none of the bad counter are not incrementing.
Has anyone on the list experienced something like this? Or have any troubleshooting advice?
Thx
Mike Partyka
Mike,
Do you have enough space on your source filer to try the QSM locally, i.e. create a new flexvol on the source filer and try to QSM to it?
--Carl
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Mike Partyka Sent: Wednesday, November 07, 2007 1:10 PM To: Mailing Lists Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Yes, although it from the source logs you can see it doesn't hang in the "exact" same place it's always around 83G transferred. I reconfigured the VSM to a QSM this morning since it's really just qtree tree1 in the flexvol and it hung even sooner, at the 65G mark. I'm trying to get downtime to run wafl_iron at this point. I just don't know what else to do.
-----Original Message----- From: Mailing Lists [mailto:mlists@uyema.net] Sent: Wed 11/7/2007 12:06 PM To: Mike Partyka Cc: NetApp Toasters List Subject: Re: Snapmirror initialization aborts consistently
It isn't clear whether you tried initializing again where it left off. Does it abort without continuing past 83gb?
On Nov 6, 2007, at 2:50 PM, "Mike Partyka" mpartyka@acmn.com wrote:
Hello,
I'm having a problem with Async SnapMirror where i have a 500G flexvol on both source and destination. When i initialize it fails at 83G consistently, I've destroyed the volume and rebuilt it several times but the problem reoccurs each time. I've run the source snapmirror logs relating to the failure through the syslog translator and all it really says is that "this is a generic snapmirror error on source", which just isn't very helpful.
Here are the logs from the source: Tue Nov 6 16:04:46 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:04:46 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed. Tue Nov 6 16:26:36 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:26:36 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed.
The source 3050a is running DOT 7.0.5 and the destination is running DOT 7.0.6
The volume options are identical as far as i can tell based on the "vol options -v data_vol" command.
The filers sites are connected via a GbE MAN, so bandwidth isn't the problem.
I've checked for errors on the ethernet interfaces on both ends and none of the bad counter are not incrementing.
Has anyone on the list experienced something like this? Or have any troubleshooting advice?
Thx
Mike Partyka
Yes, i do, and i suppose this would tell us if it's a data consistency issue or perhaps more network oriented. I think that is a fine idea, i'll give it a try tonight.
Thanks for the suggestion
-----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Wed 11/7/2007 1:54 PM To: Mike Partyka Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Mike,
Do you have enough space on your source filer to try the QSM locally, i.e. create a new flexvol on the source filer and try to QSM to it?
--Carl
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Mike Partyka Sent: Wednesday, November 07, 2007 1:10 PM To: Mailing Lists Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Yes, although it from the source logs you can see it doesn't hang in the "exact" same place it's always around 83G transferred. I reconfigured the VSM to a QSM this morning since it's really just qtree tree1 in the flexvol and it hung even sooner, at the 65G mark. I'm trying to get downtime to run wafl_iron at this point. I just don't know what else to do.
-----Original Message----- From: Mailing Lists [mailto:mlists@uyema.net] Sent: Wed 11/7/2007 12:06 PM To: Mike Partyka Cc: NetApp Toasters List Subject: Re: Snapmirror initialization aborts consistently
It isn't clear whether you tried initializing again where it left off. Does it abort without continuing past 83gb?
On Nov 6, 2007, at 2:50 PM, "Mike Partyka" mpartyka@acmn.com wrote:
Hello,
I'm having a problem with Async SnapMirror where i have a 500G flexvol on both source and destination. When i initialize it fails at 83G consistently, I've destroyed the volume and rebuilt it several times but the problem reoccurs each time. I've run the source snapmirror logs relating to the failure through the syslog translator and all it really says is that "this is a generic snapmirror error on source", which just isn't very helpful.
Here are the logs from the source: Tue Nov 6 16:04:46 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:04:46 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed. Tue Nov 6 16:26:36 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:26:36 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed.
The source 3050a is running DOT 7.0.5 and the destination is running DOT 7.0.6
The volume options are identical as far as i can tell based on the "vol options -v data_vol" command.
The filers sites are connected via a GbE MAN, so bandwidth isn't the problem.
I've checked for errors on the ethernet interfaces on both ends and none of the bad counter are not incrementing.
Has anyone on the list experienced something like this? Or have any troubleshooting advice?
Thx
Mike Partyka
Was this ever resolved? This one is too good to let go. This is going in my knowledgebase data base.
James
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Mike Partyka Sent: Wednesday, November 07, 2007 12:13 PM To: Carl Howell Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Yes, i do, and i suppose this would tell us if it's a data consistency issue or perhaps more network oriented. I think that is a fine idea, i'll give it a try tonight.
Thanks for the suggestion
-----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Wed 11/7/2007 1:54 PM To: Mike Partyka Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Mike,
Do you have enough space on your source filer to try the QSM locally, i.e. create a new flexvol on the source filer and try to QSM to it?
--Carl
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Mike Partyka Sent: Wednesday, November 07, 2007 1:10 PM To: Mailing Lists Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Yes, although it from the source logs you can see it doesn't hang in the "exact" same place it's always around 83G transferred. I reconfigured the VSM to a QSM this morning since it's really just qtree tree1 in the flexvol and it hung even sooner, at the 65G mark. I'm trying to get downtime to run wafl_iron at this point. I just don't know what else to do.
-----Original Message----- From: Mailing Lists [mailto:mlists@uyema.net] Sent: Wed 11/7/2007 12:06 PM To: Mike Partyka Cc: NetApp Toasters List Subject: Re: Snapmirror initialization aborts consistently
It isn't clear whether you tried initializing again where it left off. Does it abort without continuing past 83gb?
On Nov 6, 2007, at 2:50 PM, "Mike Partyka" mpartyka@acmn.com wrote:
Hello,
I'm having a problem with Async SnapMirror where i have a 500G flexvol on both source and destination. When i initialize it fails at 83G consistently, I've destroyed the volume and rebuilt it several times but the problem reoccurs each time. I've run the source snapmirror logs relating to the failure through the syslog translator and all it really says is that "this is a generic snapmirror error on source", which just isn't very helpful.
Here are the logs from the source: Tue Nov 6 16:04:46 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:04:46 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed. Tue Nov 6 16:26:36 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:26:36 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed.
The source 3050a is running DOT 7.0.5 and the destination is running DOT 7.0.6
The volume options are identical as far as i can tell based on the "vol options -v data_vol" command.
The filers sites are connected via a GbE MAN, so bandwidth isn't the problem.
I've checked for errors on the ethernet interfaces on both ends and none of the bad counter are not incrementing.
Has anyone on the list experienced something like this? Or have any troubleshooting advice?
Thx
Mike Partyka
Not quite yet, I will have more information after this Monday's morning appointment and I'll pass on the results to the list.
-Mike
-----Original Message----- From: Johnson, James A [HDS] [mailto:James.Johnson8@hdsupply.com] Sent: Friday, December 14, 2007 3:41 PM To: Mike Partyka; Carl Howell Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Was this ever resolved? This one is too good to let go. This is going in my knowledgebase data base.
James
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Mike Partyka Sent: Wednesday, November 07, 2007 12:13 PM To: Carl Howell Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Yes, i do, and i suppose this would tell us if it's a data consistency issue or perhaps more network oriented. I think that is a fine idea, i'll give it a try tonight.
Thanks for the suggestion
-----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Wed 11/7/2007 1:54 PM To: Mike Partyka Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Mike,
Do you have enough space on your source filer to try the QSM locally, i.e. create a new flexvol on the source filer and try to QSM to it?
--Carl
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Mike Partyka Sent: Wednesday, November 07, 2007 1:10 PM To: Mailing Lists Cc: NetApp Toasters List Subject: RE: Snapmirror initialization aborts consistently
Yes, although it from the source logs you can see it doesn't hang in the "exact" same place it's always around 83G transferred. I reconfigured the VSM to a QSM this morning since it's really just qtree tree1 in the flexvol and it hung even sooner, at the 65G mark. I'm trying to get downtime to run wafl_iron at this point. I just don't know what else to do.
-----Original Message----- From: Mailing Lists [mailto:mlists@uyema.net] Sent: Wed 11/7/2007 12:06 PM To: Mike Partyka Cc: NetApp Toasters List Subject: Re: Snapmirror initialization aborts consistently
It isn't clear whether you tried initializing again where it left off. Does it abort without continuing past 83gb?
On Nov 6, 2007, at 2:50 PM, "Mike Partyka" mpartyka@acmn.com wrote:
Hello,
I'm having a problem with Async SnapMirror where i have a 500G flexvol on both source and destination. When i initialize it fails at 83G consistently, I've destroyed the volume and rebuilt it several times but the problem reoccurs each time. I've run the source snapmirror logs relating to the failure through the syslog translator and all it really says is that "this is a generic snapmirror error on source", which just isn't very helpful.
Here are the logs from the source: Tue Nov 6 16:04:46 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:04:46 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed. Tue Nov 6 16:26:36 CST [pipeline_3:notice]: snapmirror: Network communication error Tue Nov 6 16:26:36 CST [snapmirror.src.err:error]: SnapMirror source transfer from data to hci2:rcv_data : transfer failed.
The source 3050a is running DOT 7.0.5 and the destination is running DOT 7.0.6
The volume options are identical as far as i can tell based on the "vol options -v data_vol" command.
The filers sites are connected via a GbE MAN, so bandwidth isn't the problem.
I've checked for errors on the ethernet interfaces on both ends and none of the bad counter are not incrementing.
Has anyone on the list experienced something like this? Or have any troubleshooting advice?
Thx
Mike Partyka
-
Carl Howell -
Johnson, James A [HDS] -
Mike Partyka