long slow writing before tape is marked as full

[pike]

Dear all,
we use networker 7.1.2 on W2K with a IBM Tape Library 3584. The type
of drives are 3592 also the tapes. The backup is very fast (80-100
MB/s) but when the tape becomes full we have a long time (3-5 hours)
sometimes more with slow writing. The speed decrease to 50-100 KB/s.
After 3-5 hours we got a message like this:

9/02/06 04:40:46 nsrd: write completion notice: Writing to volume
110129JA complete
09/02/06 04:47:12 nsrd: media warning: \\.\Tape36 opening: wfm failed:
drive status is Drive reports no error - but state is unknown
09/02/06 04:47:12 nsrd: media notice: 3592 tape 110069JA on \\.\Tape36
is full
09/02/06 04:47:12 nsrd: media notice: 3592 tape 110069JA used 651 GB of
500 GB capacity
09/02/06 04:47:53 nsrd: media info: verification of volume "110069JA",
volid 2615793425 succeeded.
09/02/06 04:48:11 nsrd: write completion notice: Writing to volume
110069JA complete

has anybody experience with such problem

regards

Bernd

[michael guldan]

I've seen the 3592s perform pretty well in Solaris environments, but I don't know about windows. 

This is totally off the cuff, but i would first go with the usual suspects.

Check all your drive connections, especally if it's just one or a few of the drives exhibiting the problem.

I'd also check the device driver.  Make sure that you're using the latest and gratest IBM driver here.

If these dont resolve the issue, you might have some luck disabling CDI in the device resource.  CDI was added by NetWorker to provide more meaningful tape errors.  The problem is, that sometimes (or often depending who you ask), it can *cause* problems.

this list is by no means exhaustive or even correct :-p YMMV etc. but hopfully it's a start.

Of course, as always check the knowlege base, etc.

_michael

[Home and Small Business Techs - hasbtech.com]

Bernd,

You write:
> The backup is very fast (80-100 MB/s) but when the tape becomes full we have a long time (3-5
> hours) sometimes more with slow writing. The speed decrease to 50-100 KB/s. After 3-5 hours
> we got a message like this:

Since your writing continues past the point of "full" I would suspect
the issue is not hardware, but rather that your definition of Full is
not really Full. If you have several streams of data writing to tape,
it can write out at 80-100MB/s. Toward the end of the tape, I suspect
you stream count to the drive in question drops to only one or two
streams. At this point, you are writing as fast as a single client can
push data. This can cause very fast drives to 'shoe-shine' the tape,
causing networker to slow down even more. NetWorker will not stop
writing to a tape until it gets an error from the drive (EOM - end of
media).

This of course will yield an error (it does every time) which NetWorker
dutifully reports since it is not getting EOM. You might ask IBM or MS
what wfm is (or check your driver settings for mention of it), I
suspect this is substituting EOM for unknown.

Michael is of course right about checking the ususal suspects: drivers,
RSM, physical connections, etc. (I take exception to the CDI issue;
there has never been a bug filed against CDI that turned out to be a
bug in CDI. CDI, as I understand it, just gets more information from
the driver that had been falling on the floor before. It does not
actually get status from the device itself.)

-Kevin

[michael guldan]

On 9/8/06, Home and Small Business Techs - hasbtech.com <hasb...@gmail.com > wrote:

Bernd,

You write:
> The backup is very fast (80-100 MB/s) but when the tape becomes full we have a long time (3-5
> hours) sometimes more  with slow  writing. The speed decrease to 50-100 KB/s. After 3-5 hours
> we got a message like this:

Since your writing continues past the point of "full" I would suspect
the issue is not hardware, but rather that your definition of Full is
not really Full. If you have several streams of data writing to tape,

it can write out at 80-100MB/s. Toward the end of the tape, I suspect
you stream count to the drive in question drops to only one or two
streams. At this point, you are writing as fast as a single client can
push data. This can cause very fast drives to 'shoe-shine' the tape,
causing networker to slow down even more. NetWorker will not stop
writing to a tape until it gets an error from the drive (EOM - end of
media).

It's true that NW will write till the end of tape, but when it reaches that point the  volume is marked as full.

Here's what happens (or should happen) from the NetWorker Admin Guide for v7.1 Windows page 338:

"When Used is equal to full, there is no more space on the
volume and the end-of-tape marker has been reached or an error with the
media has occurred. This is in contrast to a Used value of 100%, which
means that the value of Written is equal to, or exceeds, the estimate for
this volume."

The point is well noted about the streams  and shoeshining, but if the volume is full this should be going to a new tape.

Bernd:  Are you sure that the media is marked as full?  Does it do this every time?

This of course will yield an error (it does every time) which NetWorker
dutifully reports since it is not getting EOM. You might ask IBM or MS
what wfm is (or check your driver settings for mention of it), I
suspect this is substituting EOM for unknown.

wfm might equal "Write File Mark" or "Wired for Management" depending on who you ask.  My guess is the former. 
 

Michael is of course right about checking the ususal suspects: drivers,
RSM, physical connections, etc. (I take exception to the CDI issue;
there has never been a bug filed against CDI that turned out to be a
bug in CDI. CDI, as I understand it, just gets more information from

I take exception to your exception  :-)

I know I've seen a few Support Notes regarding CDI in the past and specifically with this version of NW.  While CDI should not be causing errors on the drive itself, CDI can effect how NetWorker interprets errors. Turning this off could stop problems from an overly noisy or problematic driver (or drive firmware).  I've had support take me through turning off CDI in numerous envionments and it has solved the problems roughly 70% of the time.  I especally see problems with CDI in Fibre Channel environments

the driver that had been falling on the floor before. It does not
actually get status from the device itself.)

I'm thinking it does.  I'll read up on the cdi_* commands and get back to you

 

-Kevin

[pike]

Dear all,
thank you for your support.
The CDI for all drives are disabled also the RSM.
The problem occurs with every full or nearly full tape. There is no
different whether the drive has one or more client connection.
We got a new devices driver.. so we will test the drives on a new
LegatoServer

regards
Bernd

[michael]

Sorry this isn't working out for you.. if new hardware dosent work, I
don't know what to tell you.. have you checked with support?

Please let us know how this gets resolved.

_m