ADSM-L

Re: SUSPECT: (MSW) Re: Internal server error on 5.3 Tape processing

2005-09-16 03:42:47
Subject: Re: SUSPECT: (MSW) Re: Internal server error on 5.3 Tape processing
From: PAC Brion Arnaud <Arnaud.Brion AT PANALPINA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 16 Sep 2005 09:42:38 +0200
Wanda, Tim,

Thanks for your information : doesn't help me much, but at least I know
I'm not the only one facing such strange problems ... 
Hopefully IBM will clear this out (already have two PMR's opened with
them, no solution so far) !
Cheers.


Arnaud 

************************************************************************
******
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone:  +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
************************************************************************
******

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Rushforth, Tim
Sent: Thursday, 15 September, 2005 17:54
To: ADSM-L AT VM.MARIST DOT EDU
Subject: SUSPECT: (MSW) Re: Internal server error on 5.3 Tape processing

We've seen something similar with the internal server error message.

We've got a PMR (#63524) open on it and have sent support traces.

We are also at 5.3.1.3.  We've gotten the error on reclaims, move data,
migrations and client backing up directly to tape.  We've had about 6
occurrences of the problem since our upgrade on Aug 8th.

We've seen the error when data is spanning tapes, one tape fills up then
it fails when writing to the second tape.  We've found a bypass is to
mark the first tape readonly then the data can be successfully written
to the second tape (in fact the same tape that failed when the data was
spanned).  I think all of our occurrences have been filling tapes for
the second tape.

We've just sent a more detailed trace but support initially replied
with:

"At this point in time, the belief is that some of your volumes that
were written to prior to the upgrade were written at a different block
size.  Looking at the q vol output there is a total of 49 tapes that are
in a filling read/write state.  The expectation is that this problem
will not affect new scratch tapes that are written to."

But we've confirmed that this has happened to new scratch tapes after
the upgrade.

The messages we get for migration are like:

09/14/2005 16:51:23      ANR9999D afcreate.c(1103): ThreadId<54>
Unexpected result 
                          code (45) from ssCopy. (PROCESS: 200)

09/14/2005 16:51:24      ANR9999D ThreadId<54> issued message 9999 from:

                          (PROCESS: 200)

09/14/2005 16:51:24      ANR1032W Migration process 200 terminated for
storage pool
                          BACKUPPOOL - internal server error detected.
(PROCESS:   
                          200)

09/14/2005 16:51:24      ANR9999D ThreadId<54> issued message 1032 from:

                          (PROCESS: 200)  

Tim Rushforth
City of Winnipeg   
                                                                     
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: Thursday, September 15, 2005 10:36 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Space reclamation error for volumes dedicated to directory
structure storage ....

I upgraded one server to 5.3.1.3 a couple of weeks ago.
Had one occurance of something similar; only my reclaim just said
"internal server error" and died.
Restarting reclaim didn't fix it.

But my reclaim was appending data to a "filling" tape that was almost
full.
I directed it to a different tape with MOVE DATA instead of reclaim, and
it finished OK.

Have seen nothing else strange.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: SUSPECT: (MSW) Re: Internal server error on 5.3 Tape processing, PAC Brion Arnaud <=