Pablo,
I am seeing the same problem with Budtool 4.6.1a (and previously with 4.6). Budtool support is claiming that it is a hardware issue. They insisted I install OnTap 5.3.5, which is certified with 4.6.1a, but this did not solved the problem. After discussion with NetApp, and reading some of the recent posts here, I am going to 5.3.5R2P2, which is supposed to fix various NDMP problems.
We are using a Breece Hill Q2.15 with 2 DLT7000 drives. The error I receive in the budtool log is:
04/27/00 23:38:39> Unload volume : B0113 04/27/00 23:40:02> ------------------------------------------------------------------ 04/27/00 23:40:02> ------ W A R N I N G ------- 04/27/00 23:40:02> Close Volume B0113 failed: Error 0 04/27/00 23:40:02> This failure, by itself, does not mean that the volume 04/27/00 23:40:02> or any of the data already on the volume is unusable. 04/27/00 23:40:02> ------------------------------------------------------------------
Then I have to manually eject the disk from the drive.
I will write back if the new OnTap version helps.
Moshe
From owner-toasters@mathworks.com Thu May 4 03:42:40 2000 Date: Wed, 3 May 2000 17:17:05 -0500 (CDT) From: Paul Mikulencak paul.mikulencak@amd.com To: "Linn, Greg" Greg.Linn@netapp.com Cc: "'toasters@mathworks.com'" toasters@mathworks.com Subject: Re: Data OnTap 5.3.5P2 and NDMP Backups Mime-Version: 1.0 Precedence: bulk
On Wed, 3 May 2000, Linn, Greg wrote:
A NDMP-based backup problem has been identified in our Data OnTap 5.3.5P2 patch release.
During development of Data OnTap 5.3.6, a deadlock condition was discovered which impacted the NDMP Java implementation. This condition typically manifests itself as an NDMP connection failure during resource depletion conditions. We believe it was first introduced 5.3.5P2. The problem has been resolved in 5.3.5R2P2 and in the forthcoming 5.3.6 release.
If you are running 5.3.5P2, and are experiencing NDMP backup problems similar to the connection failure described above, we recommend that you upgrade to 5.3.5R2P2.
greg (and all),
i'd appreciate a pointer to a description of the "problem" in detail.
we're wrestling with something here that i've been assuming was a hardware problem on our storagetek 9740 tape changer, but which hasn't responded to anything i or the storagetek field engineer have tried.
our backups (budtool, 4.6.1, with the jumbo patch, dlt7000 drives scsi attached to each F760 filer) have been failing because fully written tapes are incompletely ejected from their drives.
nothing in the messages file on either the budtool host or the netapps in question. tape drives have been replaced (for one filer, three times), and we even replaced the robotic hand. manual loading and unloading of tapes via the storagetek touch panel work without failure. sysconfig -t always shows the drives it should, and budtool always sees them.
i have a hard time laying this at the feet of the particular revision of data ontap we're running (currently 5.3.5R2P1, formerly 5.3.4R2), but most of the hardware angles have been explored. i've been reading messages on the toasters list that indicates that a bunch of folks are having problems with their backups, but nothing quite like what we're experiencing.
anyone have any feedback?
pablo
email paul.mikulencak@amd.com ext. 602-2448 "the word pessimism bothers me pager 624-0929 because it is often used instead cube 3.277.042 of the word lucidity."
robert bresson
----------------------------------------------------------------------------- Moshe Linzer | Mastery of Unix offers real freedom. Unix Systems Manager | The price of freedom is always dear, but National Semiconductor, Israel | I'd rather pay for my freedom than live in Phone: 972-9-970-2247 | a bitmapped, pop-up-happy dungeon like NT. Fax: 972-9-970-2001 | Email: moshel@nsc.com | - Thomas Scoville, Unix Review -----------------------------------------------------------------------------
On Thu, 4 May 2000, Moshe Linzer wrote:
I am seeing the same problem with Budtool 4.6.1a (and previously with 4.6). Budtool support is claiming that it is a hardware issue. They insisted I install OnTap 5.3.5, which is certified with 4.6.1a, but this did not solved the problem. After discussion with NetApp, and reading some of the recent posts here, I am going to 5.3.5R2P2, which is supposed to fix various NDMP problems.
We are using a Breece Hill Q2.15 with 2 DLT7000 drives. The error I receive in the budtool log is:
04/27/00 23:38:39> Unload volume : B0113 04/27/00 23:40:02> ------------------------------------------------------------------ 04/27/00 23:40:02> ------ W A R N I N G ------- 04/27/00 23:40:02> Close Volume B0113 failed: Error 0 04/27/00 23:40:02> This failure, by itself, does not mean that the volume 04/27/00 23:40:02> or any of the data already on the volume is unusable. 04/27/00 23:40:02> ------------------------------------------------------------------
Then I have to manually eject the disk from the drive.
I will write back if the new OnTap version helps.
moshe (and all who have responded),
many thanks for the feedback. we also are going to try 5.3.5R2P2 on at least the worst of our problem children to see if it helps.
we get the same "close volume failed" error.
the problem has now shown up on one of our atl 7/100 tape changers as well, so it's harder for me to blame this on the storagetek hardware alone.
i'll also write back with our results.
many thanks again to all who've offered feedback.
pablo
email paul.mikulencak@amd.com ext. 602-2448 "the word pessimism bothers me pager 624-0929 because it is often used instead cube 3.277.042 of the word lucidity."
robert bresson
From owner-toasters@mathworks.com Thu May 4 03:42:40 2000 Date: Wed, 3 May 2000 17:17:05 -0500 (CDT) From: Paul Mikulencak paul.mikulencak@amd.com To: "Linn, Greg" Greg.Linn@netapp.com Cc: "'toasters@mathworks.com'" toasters@mathworks.com Subject: Re: Data OnTap 5.3.5P2 and NDMP Backups Mime-Version: 1.0 Precedence: bulk
On Wed, 3 May 2000, Linn, Greg wrote:
A NDMP-based backup problem has been identified in our Data OnTap 5.3.5P2 patch release.
During development of Data OnTap 5.3.6, a deadlock condition was discovered which impacted the NDMP Java implementation. This condition typically manifests itself as an NDMP connection failure during resource depletion conditions. We believe it was first introduced 5.3.5P2. The problem has been resolved in 5.3.5R2P2 and in the forthcoming 5.3.6 release.
If you are running 5.3.5P2, and are experiencing NDMP backup problems similar to the connection failure described above, we recommend that you upgrade to 5.3.5R2P2.
greg (and all),
i'd appreciate a pointer to a description of the "problem" in detail.
we're wrestling with something here that i've been assuming was a hardware problem on our storagetek 9740 tape changer, but which hasn't responded to anything i or the storagetek field engineer have tried.
our backups (budtool, 4.6.1, with the jumbo patch, dlt7000 drives scsi attached to each F760 filer) have been failing because fully written tapes are incompletely ejected from their drives.
nothing in the messages file on either the budtool host or the netapps in question. tape drives have been replaced (for one filer, three times), and we even replaced the robotic hand. manual loading and unloading of tapes via the storagetek touch panel work without failure. sysconfig -t always shows the drives it should, and budtool always sees them.
i have a hard time laying this at the feet of the particular revision of data ontap we're running (currently 5.3.5R2P1, formerly 5.3.4R2), but most of the hardware angles have been explored. i've been reading messages on the toasters list that indicates that a bunch of folks are having problems with their backups, but nothing quite like what we're experiencing.
anyone have any feedback?
pablo
email paul.mikulencak@amd.com ext. 602-2448 "the word pessimism bothers me pager 624-0929 because it is often used instead cube 3.277.042 of the word lucidity."
robert bresson
Moshe Linzer | Mastery of Unix offers real freedom. Unix Systems Manager | The price of freedom is always dear, but National Semiconductor, Israel | I'd rather pay for my freedom than live in Phone: 972-9-970-2247 | a bitmapped, pop-up-happy dungeon like NT. Fax: 972-9-970-2001 | Email: moshel@nsc.com | - Thomas Scoville, Unix Review
-
Moshe Linzer -
Paul Mikulencak