Re: Media Fault

[Zlatko Krastev]

A long, long time ago ... there was a discussion I missed. An attempt to
catch up two months later.

--> Useage numbers are kept for a "volume", not for a "libvol" ...

The information about libvolumes is kept in volume history. Usually we do
not delete it beyond DB backups and DB snapshots. So you can try

select volume_name as "Volume___",count(*)
as "number of uses" from volhistory where devclass='' and
(type='STGNEW' or type='STGREUSE') group by volume_name order by 2 desc

Zlatko Krastev
IT Consultant






Roger Deschner <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
30.06.2003 19:38
Please respond to "ADSM: Dist Stor Manager"


To: [EMAIL PROTECTED]
cc:
Subject:Re: Media Fault


I am having a pattern of this as well. I think that some tapes in my
library are being used much more heavily than others, and they are
simply wearing out.

I started out in December 2002 with all new SDLT tapes and a brand-new
library with new drives. Since then 3 of the new tapes have had this
"media fault" condition. As I am researching this, I am finding that
they are among the most heavily used tapes.

ITSM does not give us any decent statistics on this. Useage numbers are
kept for a "volume", not for a "libvol", which is a serious shortcoming.
This means that these useage and error statistics are lost each time a
tape is reclaimed and returned to the scratch pool.

What I am finding on these failed tapes, by scanning the activity log,
is that they are used and reclaimed very frequently. This is due to the
nature of the clients being backed up to that storage pool tree - they
are email servers, so there is a very high turnover of files on those
clients. Email-server clients would appear to wear out the tapes used to
back them up.

I'm also suspicious that my tape-to-tape reclamation causes less than
optimal tape movement, by interfering with streaming. My planned
addition of a reclamation disk storage pool may actually help extend
tape media life, by allowing the drive to stream on both input and
output.

I'm actually glad to hear this happens with LTO as well - I was
beginning to suspect my choice of SDLT over LTO was a mistake.

Roger Deschner  University of Illinois at Chicago [EMAIL PROTECTED]


On Sun, 29 Jun 2003, Anwer Adil wrote:

>I am getting the following error:
>
>ANR8302E I/O error on drive DRIVE2 (mt2.0.0.5) (OP=LOCATE, Error
Number=23,
>CC=0, KEY=03, ASC=14, ASCQ=00,
>SENSE=70.00.03.00.00.00.00.1C.00.00.00.00.14.00.06.00.20.80.00.00.00.00.00.00.
>-
>00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.
>-
>00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.
>-
>00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00,
>Description=An undetermined error has occurred).  Refer to Appendix D in
>the
>'Messages' manual for recommended action.
>ANR8359E Media fault detected on LTO volume 24 in drive DRIVE2
>(mt2.0.0.5)
>of library IBM3583.
>
>Over the period of one month, tsm have reported media fault on 5
different
>tapes. Every week, a different tape is reporting error. IBM CEs checked
the
>hardware to ensure that the tape drives and the library have the latest
>firmware. They also ran a diagnostic on the library and didn't find a
>problem. Tape drives are fine since the same tape reports error on
>different drives. I end up restoring the bad tape from the second copy
>every time I see this problem.
>
>I am using IBM3583 library with 3 lto drives. TSM version is 5.1.1.0.
>
>Please help as I am clueless at this point.
>
>Anwer Adil
>

Re: How to read LTO cartridge memory (was Re: Media Fault)

[Marcel J.E. Mol]

Hi list,

new patches are including logpage 30 and power uptime on logpage c are
available on http://www.mesa.nl

-Marcel

On Wed, Aug 27, 2003 at 06:27:20PM +0200, Anthonijsz, Marcel M SITI-ITDGE13 wrote:
> Hurray,
>
> With the help of Marcel Mol (Thanks!)I managed to read the wanted info from
> LTO CM. Marcel provides a patch on his site for tapeutil (see below). The patched
> tapeutil displays the log page info in human readable format (again, see below).
> I added (read copied and altered) some code to display Log Page 30 "Tape Usage Log".
> Now tapeutil -f /dev/rmt1 logpage 30 says following:
>
> Enter page code in hex: 30
>
> Enter parameter pointer in hex or  for all parameters:
> Issuing log sense for page 0x30...
>  1 - Thread Count:112
>  2 - Total Data Sets Written: 3245519
>  3 - Total Write Retries: 1336616
>  4 - Total Unrecovered Write Errors:0
>  5 - Total Suspended Writes:28027
>  6 - Total Fatal Suspended Writes:  0
>  7 - Total Data Sets Read: 666434
>  8 - Total Read Retries:   88
>  9 - Total Unrecovered Read Errors: 0
> 10 - Total Suspended Reads: 0
> 11 - Total Fatal Suspended Reads:   0
>
> And the thread count is increased each time the cartridge is loaded into a drive.
> Now only I have to find out what the relevance of the other figures are...
> Help apriciated!
>
> And - yes - it's radio technology, you have to put the cartridge into a drive to get
> readings (bummer!), otherwise it's all zeroes.. Now I can get stats for all my
> 1000 cartridges...
>
> See "IBM TotalStorage LTO Ultrium Tape Drive SCSI Reference GA32-0450" for detailed
> info. http://www.ibm.com/Search?v=11&lang=en&cc=us&q=GA32-0450
>
> Marcel Anthonijsz
> Central Data Storage Manager (a.k.a. storman)
> Shell Information Technology International B.V.
> PO Box 1027, 2260 BA  Leidschendam, The Netherlands
>
> Tel: +31-70 303 4984
> Email: Marcel.Anthonijsz.at.shell.com
> Internet: http://www.shell.com
>
>
>
> Date:Tue, 26 Aug 2003 19:48:26 +0200
> From:"Marcel J.E. Mol" <[EMAIL PROTECTED]>
> Subject: Re: How to read LTO cartridge memory (was Re: Media Fault)
>
> On Tue, Aug 26, 2003 at 01:14:21PM +0200, Anthonijsz, Marcel M SITI-ITDGE13 wrote:
> > Hi *SM'ers,
> >
> > Does anybody know how to read the LTO Cartridge memory from the LTO cartridge?
>
> Is this the output you would like to see?
>
> Issuing log sense for page 0x0C...
>0 - Write Bytes Received before Compression:0
>1 - Write Bytes Received after Compression: 0
>2 - Read Bytes Sent before Compression: 0
>3 - Read Bytes Sent after Compression:  0
> 0100 - Cleaning Required:  0
> 8000 - Megabytes processed since last cleaning: 20598158
> 8001 - Lifetime Load Cycles:1313
> 8002 - Lifetime Cleaning Cycles:   1
>
> I created this by patching the tapeutil command a bit. It decodes the
> data from logpages C, 31 and 32.
>
>
> See http://www.mesa.nl for the patches. Follwo the download section...
>
> -Marcel
>
>
> > The LTO specs/brochure show an expected life cycle of about 1 million mounts and 
> > recommends replacement after about 5000 loads.
> > We want to know how close we are to this figure. TSM forgets about mounts as soon 
> > as a volume gets scratched...
> >
> > Now did somebody perform the exercise Richards Sims describes below?
> > If not... I see an opportunity here I never did SCSI programming, so there 
> > must a first time for everything :-/
> >
> > Thanks!
> >
> > Marcel Anthonijsz
> > Central Data Storage Manager (a.k.a. storman)
> > Shell Information Technology International B.V.
> > PO Box 1027, 2260 BA  Leidschendam, The Netherlands
> >
> > Email: Marcel.Anthonijsz.-at-.shell.com
> > Internet: http://www.shell.com
> >
> > Date:  Jul 01, 09:42
> > From:  Richard Sims <[EMAIL PROTECTED]>
> >
> > >Question is: Do you possibly know any software capable of extracting info
> > >from LTO CM??
> > >(I mean of course a program that can be run against a suspected cartridge)
> > >
> > >Wieslaw
> >
> > Now, you know you weren't supposed to ask that question...  :-)
> >
> > M

Re: How to read LTO cartridge memory (was Re: Media Fault)

[Anthonijsz, Marcel M SITI-ITDGE13]

Hurray,

With the help of Marcel Mol (Thanks!)I managed to read the wanted info from
LTO CM. Marcel provides a patch on his site for tapeutil (see below). The patched
tapeutil displays the log page info in human readable format (again, see below).
I added (read copied and altered) some code to display Log Page 30 "Tape Usage Log".
Now tapeutil -f /dev/rmt1 logpage 30 says following:

Enter page code in hex: 30
 
Enter parameter pointer in hex or  for all parameters: 
Issuing log sense for page 0x30...
 1 - Thread Count:112
 2 - Total Data Sets Written: 3245519
 3 - Total Write Retries: 1336616
 4 - Total Unrecovered Write Errors:0
 5 - Total Suspended Writes:28027
 6 - Total Fatal Suspended Writes:  0
 7 - Total Data Sets Read: 666434
 8 - Total Read Retries:   88
 9 - Total Unrecovered Read Errors: 0
10 - Total Suspended Reads: 0
11 - Total Fatal Suspended Reads:   0

And the thread count is increased each time the cartridge is loaded into a drive.
Now only I have to find out what the relevance of the other figures are...
Help apriciated!

And - yes - it's radio technology, you have to put the cartridge into a drive to get
readings (bummer!), otherwise it's all zeroes.. Now I can get stats for all my
1000 cartridges... 

See "IBM TotalStorage LTO Ultrium Tape Drive SCSI Reference GA32-0450" for detailed 
info. http://www.ibm.com/Search?v=11&lang=en&cc=us&q=GA32-0450

Marcel Anthonijsz
Central Data Storage Manager (a.k.a. storman)
Shell Information Technology International B.V.
PO Box 1027, 2260 BA  Leidschendam, The Netherlands

Tel: +31-70 303 4984
Email: Marcel.Anthonijsz.at.shell.com
Internet: http://www.shell.com



Date:Tue, 26 Aug 2003 19:48:26 +0200
From:"Marcel J.E. Mol" <[EMAIL PROTECTED]>
Subject: Re: How to read LTO cartridge memory (was Re: Media Fault)

On Tue, Aug 26, 2003 at 01:14:21PM +0200, Anthonijsz, Marcel M SITI-ITDGE13 wrote:
> Hi *SM'ers,
>
> Does anybody know how to read the LTO Cartridge memory from the LTO cartridge?

Is this the output you would like to see?

Issuing log sense for page 0x0C...
   0 - Write Bytes Received before Compression:0
   1 - Write Bytes Received after Compression: 0
   2 - Read Bytes Sent before Compression: 0
   3 - Read Bytes Sent after Compression:  0
0100 - Cleaning Required:  0
8000 - Megabytes processed since last cleaning: 20598158
8001 - Lifetime Load Cycles:1313
8002 - Lifetime Cleaning Cycles:   1

I created this by patching the tapeutil command a bit. It decodes the
data from logpages C, 31 and 32.


See http://www.mesa.nl for the patches. Follwo the download section...

-Marcel


> The LTO specs/brochure show an expected life cycle of about 1 million mounts and 
> recommends replacement after about 5000 loads.
> We want to know how close we are to this figure. TSM forgets about mounts as soon as 
> a volume gets scratched...
>
> Now did somebody perform the exercise Richards Sims describes below?
> If not... I see an opportunity here I never did SCSI programming, so there must 
> a first time for everything :-/
>
> Thanks!
>
> Marcel Anthonijsz
> Central Data Storage Manager (a.k.a. storman)
> Shell Information Technology International B.V.
> PO Box 1027, 2260 BA  Leidschendam, The Netherlands
>
> Email: Marcel.Anthonijsz.-at-.shell.com
> Internet: http://www.shell.com
>
> Date:  Jul 01, 09:42
> From:  Richard Sims <[EMAIL PROTECTED]>
>
> >Question is: Do you possibly know any software capable of extracting info
> >from LTO CM??
> >(I mean of course a program that can be run against a suspected cartridge)
> >
> >Wieslaw
>
> Now, you know you weren't supposed to ask that question...  :-)
>
> My research indicates that vendors don't consider that customers should need
> to access the Medium Auxiliary Memory (MAM) - the industry generic name for
> an in-cartridge non-volatile memory chip which tracks usage and other info.
> The manual "IBM TotalStorage LTO Ultrium Tape Drive - SCSI Reference"
> (GA32-4050) fully describes their MAM and how to read and write it via SCSI
> commands.  The device driver programming manual (in this case, "IBM Ultrium
> Device Drivers - Programming Reference (GC35-0483)) provides many ioctl
> functions which make it easier for a programmer to invoke what resolve to SCSI
> commands; but in this case I see no ready operation for ge

Re: How to read LTO cartridge memory (was Re: Media Fault)

[Marcel J.E. Mol]

On Tue, Aug 26, 2003 at 01:14:21PM +0200, Anthonijsz, Marcel M SITI-ITDGE13 wrote:
> Hi *SM'ers,
>
> Does anybody know how to read the LTO Cartridge memory from the LTO cartridge?

Is this the output you would like to see?

Issuing log sense for page 0x0C...
   0 - Write Bytes Received before Compression:0
   1 - Write Bytes Received after Compression: 0
   2 - Read Bytes Sent before Compression: 0
   3 - Read Bytes Sent after Compression:  0
0100 - Cleaning Required:  0
8000 - Megabytes processed since last cleaning: 20598158
8001 - Lifetime Load Cycles:1313
8002 - Lifetime Cleaning Cycles:   1

I created this by patching the tapeutil command a bit. It decodes the
data from logpages C, 31 and 32.


See http://www.mesa.nl for the patches. Follwo the download section...

-Marcel


> The LTO specs/brochure show an expected life cycle of about 1 million mounts and 
> recommends replacement after about 5000 loads.
> We want to know how close we are to this figure. TSM forgets about mounts as soon as 
> a volume gets scratched...
>
> Now did somebody perform the exercise Richards Sims describes below?
> If not... I see an opportunity here I never did SCSI programming, so there must 
> a first time for everything :-/
>
> Thanks!
>
> Marcel Anthonijsz
> Central Data Storage Manager (a.k.a. storman)
> Shell Information Technology International B.V.
> PO Box 1027, 2260 BA  Leidschendam, The Netherlands
>
> Email: Marcel.Anthonijsz.-at-.shell.com
> Internet: http://www.shell.com
>
> Date:  Jul 01, 09:42
> From:  Richard Sims <[EMAIL PROTECTED]>
>
> >Question is: Do you possibly know any software capable of extracting info
> >from LTO CM??
> >(I mean of course a program that can be run against a suspected cartridge)
> >
> >Wieslaw
>
> Now, you know you weren't supposed to ask that question...  :-)
>
> My research indicates that vendors don't consider that customers should need
> to access the Medium Auxiliary Memory (MAM) - the industry generic name for
> an in-cartridge non-volatile memory chip which tracks usage and other info.
> The manual "IBM TotalStorage LTO Ultrium Tape Drive - SCSI Reference"
> (GA32-4050) fully describes their MAM and how to read and write it via SCSI
> commands.  The device driver programming manual (in this case, "IBM Ultrium
> Device Drivers - Programming Reference (GC35-0483)) provides many ioctl
> functions which make it easier for a programmer to invoke what resolve to SCSI
> commands; but in this case I see no ready operation for getting MAM data.
> Those ioctl operations are what the handy-dandy ntutil and tapeutil commands
> invoke to acquire info, and I see nothing in their doc saying that they can
> return it (though it might be implicitly returned from other operations).
>
> All this is to say that with some SCSI programming, the information could be
> obtained and presented.  We don't have LTO here, so I'm not in a position to
> try this out.  So this remains an exercise for some industrious systems
> programmer out there having LTO on-site.
>
>   Richard Sims, Sr. Systems Programmer, Boston University OIT
>   

--
 == Marcel J.E. MolMESA Consulting B.V.
===-ph. +31-(0)6-54724868  P.O. Box 112
===-[EMAIL PROTECTED] 2630 AC  Nootdorp
__ www.mesa.nl ---U_n_i_x__I_n_t_e_r_n_e_t The Netherlands 
 They couldn't think of a number,   Linux user 1148  --  counter.li.org
so they gave me a name!  -- Rupert Hine  --  www.ruperthine.com

Re: How to read LTO cartridge memory (was Re: Media Fault)

[Robin Sharpe]

Wouldn't that require special hardware?  It's radio, isn't it?
Robin Sharpe
Berlex Labs



  "Anthonijsz,
  Marcel M
  SITI-ITDGE13"  To: [EMAIL PROTECTED]
  Subject:
  Sent by: "ADSM:How to read LTO cartridge memory (was 
Re: Media Fault)
  Dist Stor Manager"
  <[EMAIL PROTECTED]
  EDU>


  08/26/03 07:14 AM
  Please respond to
  "ADSM: Dist Stor
  Manager"





Hi *SM'ers,

Does anybody know how to read the LTO Cartridge memory from the LTO
cartridge?
The LTO specs/brochure show an expected life cycle of about 1 million
mounts and recommends replacement after about 5000 loads.
We want to know how close we are to this figure. TSM forgets about mounts
as soon as a volume gets scratched...

Now did somebody perform the exercise Richards Sims describes below?
If not... I see an opportunity here I never did SCSI programming, so
there must a first time for everything :-/

Thanks!

Marcel Anthonijsz
Central Data Storage Manager (a.k.a. storman)
Shell Information Technology International B.V.
PO Box 1027, 2260 BA  Leidschendam, The Netherlands

Email: Marcel.Anthonijsz.-at-.shell.com
Internet: http://www.shell.com

Date:  Jul 01, 09:42
From:  Richard Sims <[EMAIL PROTECTED]>

>Question is: Do you possibly know any software capable of extracting info
>from LTO CM??
>(I mean of course a program that can be run against a suspected cartridge)
>
>Wieslaw

Now, you know you weren't supposed to ask that question...  :-)

My research indicates that vendors don't consider that customers should
need
to access the Medium Auxiliary Memory (MAM) - the industry generic name for
an in-cartridge non-volatile memory chip which tracks usage and other info.
The manual "IBM TotalStorage LTO Ultrium Tape Drive - SCSI Reference"
(GA32-4050) fully describes their MAM and how to read and write it via SCSI
commands.  The device driver programming manual (in this case, "IBM Ultrium
Device Drivers - Programming Reference (GC35-0483)) provides many ioctl
functions which make it easier for a programmer to invoke what resolve to
SCSI
commands; but in this case I see no ready operation for getting MAM data.
Those ioctl operations are what the handy-dandy ntutil and tapeutil
commands
invoke to acquire info, and I see nothing in their doc saying that they can
return it (though it might be implicitly returned from other operations).

All this is to say that with some SCSI programming, the information could
be
obtained and presented.  We don't have LTO here, so I'm not in a position
to
try this out.  So this remains an exercise for some industrious systems
programmer out there having LTO on-site.

  Richard Sims, Sr. Systems Programmer, Boston University OIT
  <http://people.bu.edu/rbs>

How to read LTO cartridge memory (was Re: Media Fault)

[Anthonijsz, Marcel M SITI-ITDGE13]

Hi *SM'ers,

Does anybody know how to read the LTO Cartridge memory from the LTO cartridge?
The LTO specs/brochure show an expected life cycle of about 1 million mounts and 
recommends replacement after about 5000 loads.
We want to know how close we are to this figure. TSM forgets about mounts as soon as a 
volume gets scratched...

Now did somebody perform the exercise Richards Sims describes below?
If not... I see an opportunity here I never did SCSI programming, so there must a 
first time for everything :-/

Thanks!

Marcel Anthonijsz
Central Data Storage Manager (a.k.a. storman)
Shell Information Technology International B.V.
PO Box 1027, 2260 BA  Leidschendam, The Netherlands

Email: Marcel.Anthonijsz.-at-.shell.com
Internet: http://www.shell.com

Date:  Jul 01, 09:42 
From:  Richard Sims <[EMAIL PROTECTED]> 

>Question is: Do you possibly know any software capable of extracting info
>from LTO CM??
>(I mean of course a program that can be run against a suspected cartridge)
>
>Wieslaw

Now, you know you weren't supposed to ask that question...  :-)

My research indicates that vendors don't consider that customers should need
to access the Medium Auxiliary Memory (MAM) - the industry generic name for
an in-cartridge non-volatile memory chip which tracks usage and other info.
The manual "IBM TotalStorage LTO Ultrium Tape Drive - SCSI Reference"
(GA32-4050) fully describes their MAM and how to read and write it via SCSI
commands.  The device driver programming manual (in this case, "IBM Ultrium
Device Drivers - Programming Reference (GC35-0483)) provides many ioctl
functions which make it easier for a programmer to invoke what resolve to SCSI
commands; but in this case I see no ready operation for getting MAM data.
Those ioctl operations are what the handy-dandy ntutil and tapeutil commands
invoke to acquire info, and I see nothing in their doc saying that they can
return it (though it might be implicitly returned from other operations).

All this is to say that with some SCSI programming, the information could be
obtained and presented.  We don't have LTO here, so I'm not in a position to
try this out.  So this remains an exercise for some industrious systems
programmer out there having LTO on-site.

  Richard Sims, Sr. Systems Programmer, Boston University OIT
  

Re: Media Fault

[Marcel J.E. Mol]

On Tue, Jul 01, 2003 at 09:42:30AM -0400, Richard Sims wrote:
> >Question is: Do you possibly know any software capable of extracting info
> >from LTO CM??
> >(I mean of course a program that can be run against a suspected cartridge)
> >
> >Wieslaw
>
> Now, you know you weren't supposed to ask that question...  :-)

What about this data for an LTO cartridge:

   0 - Write Bytes Received before Compression: 248204451840
   1 - Write Bytes Received after Compression:   55089235700
   2 - Read Bytes Sent before Compression: 0
   3 - Read Bytes Sent after Compression:  0
0100 - Cleaning Required:  0
8000 - Megabytes processed since last cleaning: 19793782
8001 - Lifetime Load Cycles: 695
8002 - Lifetime Cleaning Cycles:   0

-Marcel
--
 == Marcel J.E. MolMESA Consulting B.V.
===-ph. +31-(0)6-54724868  P.O. Box 112
===-[EMAIL PROTECTED] 2630 AC  Nootdorp
__ www.mesa.nl ---U_n_i_x__I_n_t_e_r_n_e_t The Netherlands 
 They couldn't think of a number,   Linux user 1148  --  counter.li.org
so they gave me a name!  -- Rupert Hine  --  www.ruperthine.com

Re: Media Fault

[Richard Sims]

>Question is: Do you possibly know any software capable of extracting info
>from LTO CM??
>(I mean of course a program that can be run against a suspected cartridge)
>
>Wieslaw

Now, you know you weren't supposed to ask that question...  :-)

My research indicates that vendors don't consider that customers should need
to access the Medium Auxiliary Memory (MAM) - the industry generic name for
an in-cartridge non-volatile memory chip which tracks usage and other info.
The manual "IBM TotalStorage LTO Ultrium Tape Drive - SCSI Reference"
(GA32-4050) fully describes their MAM and how to read and write it via SCSI
commands.  The device driver programming manual (in this case, "IBM Ultrium
Device Drivers - Programming Reference (GC35-0483)) provides many ioctl
functions which make it easier for a programmer to invoke what resolve to SCSI
commands; but in this case I see no ready operation for getting MAM data.
Those ioctl operations are what the handy-dandy ntutil and tapeutil commands
invoke to acquire info, and I see nothing in their doc saying that they can
return it (though it might be implicitly returned from other operations).

All this is to say that with some SCSI programming, the information could be
obtained and presented.  We don't have LTO here, so I'm not in a position to
try this out.  So this remains an exercise for some industrious systems
programmer out there having LTO on-site.

  Richard Sims, Sr. Systems Programmer, Boston University OIT
  http://people.bu.edu/rbs

Re: Media Fault

[Wieslaw Markowiak/Kra/ComputerLand/PL]

On Mon, 30 Jun 2003 14:30:41 Richard Sims wrote:

"Well, neither applications nor libraries should actually be tracking that
kind of information, given the propensity of removeable media to migrate
and periodically inhabit different locales: such statistical information
about a cartridge should be carried by the cartridge.

More modern tape technologies incorporate a non-volatile memory chip in
the cartridge to record information and track usage.  LTO has CM
(Cartridge Memory), and AIT has MIC (Memory in Cassette).  DLT and 3590,
unfortunately, lack such auxiliary memory.  (The 3590 has a Volume Control
Region at the head of the tape, for limited recording.)"

Question is: Do you possibly know any software capable of extracting info
from LTO CM??
(I mean of course a program that can be run against a suspected cartridge)


Wieslaw

Re: Media Fault

[Richard Sims]

> I started out in December 2002 with all new SDLT tapes and a brand-new
> library with new drives. Since then 3 of the new tapes have had this
> "media fault" condition. As I am researching this, I am finding that
> they are among the most heavily used tapes.
>
> ITSM does not give us any decent statistics on this. Useage numbers are
> kept for a "volume", not for a "libvol", which is a serious shortcoming.
> This means that these useage and error statistics are lost each time a
> tape is reclaimed and returned to the scratch pool.

Well, neither applications nor libraries should actually be tracking that
kind of information, given the propensity of removeable media to migrate
and periodically inhabit different locales: such statistical information
about a cartridge should be carried by the cartridge.

More modern tape technologies incorporate a non-volatile memory chip in
the cartridge to record information and track usage.  LTO has CM
(Cartridge Memory), and AIT has MIC (Memory in Cassette).  DLT and 3590,
unfortunately, lack such auxiliary memory.  (The 3590 has a Volume Control
Region at the head of the tape, for limited recording.)

  Richard Sims, BU

Re: Media Fault

[Steve Bennett]

A long, long time ago in a galaxy far, far away I wrote a bash shell
script to do a daily query of the activity log to extract tape mounts
and same them to a history file that could be used by perl to see how
long the tape has been in use and how many times it has been mounted.
Does not give any idea of how well you are streaming a tape but at least
you could know if it was really, really old or if it had been mounted a
gazillion times. I email myself alerts when a tape has reached a
predetermined age or has been mounted a certain number of times and
should be replaced. I am not fluent in shell scripts or perl so
obviously isn't that hard to do. Depending on how long you keep your
tapes and how many there are, the history file could get rather large.

Roger Deschner wrote:
>
> I am having a pattern of this as well. I think that some tapes in my
> library are being used much more heavily than others, and they are
> simply wearing out.
>
> I started out in December 2002 with all new SDLT tapes and a brand-new
> library with new drives. Since then 3 of the new tapes have had this
> "media fault" condition. As I am researching this, I am finding that
> they are among the most heavily used tapes.
>
> ITSM does not give us any decent statistics on this. Useage numbers are
> kept for a "volume", not for a "libvol", which is a serious shortcoming.
> This means that these useage and error statistics are lost each time a
> tape is reclaimed and returned to the scratch pool.


..snip

--

Steve Bennett, (907) 465-5783
State of Alaska, Information Technology Group, Technical Services
Section

Re: Media Fault

[Roger Deschner]

I am having a pattern of this as well. I think that some tapes in my
library are being used much more heavily than others, and they are
simply wearing out.

I started out in December 2002 with all new SDLT tapes and a brand-new
library with new drives. Since then 3 of the new tapes have had this
"media fault" condition. As I am researching this, I am finding that
they are among the most heavily used tapes.

ITSM does not give us any decent statistics on this. Useage numbers are
kept for a "volume", not for a "libvol", which is a serious shortcoming.
This means that these useage and error statistics are lost each time a
tape is reclaimed and returned to the scratch pool.

What I am finding on these failed tapes, by scanning the activity log,
is that they are used and reclaimed very frequently. This is due to the
nature of the clients being backed up to that storage pool tree - they
are email servers, so there is a very high turnover of files on those
clients. Email-server clients would appear to wear out the tapes used to
back them up.

I'm also suspicious that my tape-to-tape reclamation causes less than
optimal tape movement, by interfering with streaming. My planned
addition of a reclamation disk storage pool may actually help extend
tape media life, by allowing the drive to stream on both input and
output.

I'm actually glad to hear this happens with LTO as well - I was
beginning to suspect my choice of SDLT over LTO was a mistake.

Roger Deschner  University of Illinois at Chicago [EMAIL PROTECTED]


On Sun, 29 Jun 2003, Anwer Adil wrote:

>I am getting the following error:
>
>ANR8302E I/O error on drive DRIVE2 (mt2.0.0.5) (OP=LOCATE, Error Number=23,
>CC=0, KEY=03, ASC=14, ASCQ=00,
>SENSE=70.00.03.00.00.00.00.1C.00.00.00.00.14.00.06.00.20.80.00.00.00.00.00.00.
>-
>00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.
>-
>00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.
>-
>00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00,
>Description=An undetermined error has occurred).  Refer to Appendix D in
>the
>'Messages' manual for recommended action.
>ANR8359E Media fault detected on LTO volume 24 in drive DRIVE2
>(mt2.0.0.5)
>of library IBM3583.
>
>Over the period of one month, tsm have reported media fault on 5 different
>tapes. Every week, a different tape is reporting error. IBM CEs checked the
>hardware to ensure that the tape drives and the library have the latest
>firmware. They also ran a diagnostic on the library and didn't find a
>problem. Tape drives are fine since the same tape reports error on
>different drives. I end up restoring the bad tape from the second copy
>every time I see this problem.
>
>I am using IBM3583 library with 3 lto drives. TSM version is 5.1.1.0.
>
>Please help as I am clueless at this point.
>
>Anwer Adil
>

Re: Media Fault

[Bob Levad]

>>ANR8302E I/O error on drive DRIVE2 (mt2.0.0.5) (OP=LOCATE, Error
Number=23,
>>CC=0, KEY=03, ASC=14, ASCQ=00,
>...
>>Every week, a different tape is reporting error. ...
>>Tape drives are fine since the same tape reports error on different
drives.

>(*chuckle*)  Well, it could mean that all your drives are consistently
>problematic.  Refer to last week's postings about tape drive cleaning -
>the root of so many tape I/O problems.  Dirty tape drives proficiently
>spread the gunk throughout your tape complement and to other drives.
>Remember also that libraries are not hermetically sealed units - and
>computer rooms are far from being Clean Rooms.  If your library is in a
>dusty or high-traffic area, consider putting a portable air cleaner
>alongside it.

>  Richard Sims, BU

There is a new firmware level for that drive.  I have not gotten that error
message since it was applied (about 6/18).

Bob Levad

Re: Media Fault

[Richard Sims]

>ANR8302E I/O error on drive DRIVE2 (mt2.0.0.5) (OP=LOCATE, Error Number=23,
>CC=0, KEY=03, ASC=14, ASCQ=00,
...
>Every week, a different tape is reporting error. ...
>Tape drives are fine since the same tape reports error on different drives.

(*chuckle*)  Well, it could mean that all your drives are consistently
problematic.  Refer to last week's postings about tape drive cleaning -
the root of so many tape I/O problems.  Dirty tape drives proficiently
spread the gunk throughout your tape complement and to other drives.
Remember also that libraries are not hermetically sealed units - and
computer rooms are far from being Clean Rooms.  If your library is in a
dusty or high-traffic area, consider putting a portable air cleaner
alongside it.

  Richard Sims, BU

Media Fault

[Anwer Adil]

I am getting the following error:

ANR8302E I/O error on drive DRIVE2 (mt2.0.0.5) (OP=LOCATE, Error Number=23,
CC=0, KEY=03, ASC=14, ASCQ=00,
SENSE=70.00.03.00.00.00.00.1C.00.00.00.00.14.00.06.00.20.80.00.00.00.00.00.00.
-
00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.
-
00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.
-
00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00,
Description=An undetermined error has occurred).  Refer to Appendix D in
the
'Messages' manual for recommended action.
ANR8359E Media fault detected on LTO volume 24 in drive DRIVE2
(mt2.0.0.5)
of library IBM3583.

Over the period of one month, tsm have reported media fault on 5 different
tapes. Every week, a different tape is reporting error. IBM CEs checked the
hardware to ensure that the tape drives and the library have the latest
firmware. They also ran a diagnostic on the library and didn't find a
problem. Tape drives are fine since the same tape reports error on
different drives. I end up restoring the bad tape from the second copy
every time I see this problem.

I am using IBM3583 library with 3 lto drives. TSM version is 5.1.1.0.

Please help as I am clueless at this point.

Anwer Adil