HP LTO4 drive confused about its identity

[jim_dalton]

Probably more of a hardware issue but I hope theres been someone seen this before...I have an LTO4 drive in a robot with other LTO4s.

One has now started behaving erratically but doesnt show  an error.

It seems its undecided about what sort of drive it is:it advertises itself as HP ultrium lto4, but dont try putting an LTO4 tape in : it gets spat out.

Eventually I tracked this down and on the filer to which it is attached I get this response:

filer> mt -f nrst3a status

Tape drive: Hewlett-Packard LTO-4 :good

    Status: offline

    Format: LTO-2(ro)/3 2/400GB: not so good.

    fileno = -1  blockno = -1  resid = 0

so this goes some way to explain the behaviour. All thats left is to figure out why my drive now thinks it might be an lto2/3 drive having been an lto4 for all of its life so far. It and the robot have both been rebooted to no avail.

The ideal answer would not involve replacing the drive though I feel this may be optimistic.

Your input appreciated, Jim.

[GulzarShaikhAUS]

Have you tried to configure this in Netbackup. If yes, what status it shows in Netbackup. 

Also can you share the sysconfig -t output from the filer. I am assuming it is Netapp filer

[mph999]

If it spits an lto4 tape out, replacement is the only way to do, unless a firmware update helps.  Never seen anything like this before. 

Given that mt command queries the drive, can't see it being anything else. 

How our why it has decided to downgrade itself, no ideal - wouldn't have thought it was even possible, how would it know to send LTO-2.

[Nicolai]

Never seen that one before or the response from the filer is not correct.

If the tape drive is fibre channel connected you should be able to see it the SANs "name server" with SCSI inquiry ID. Hopefully this say LTO4.

[mph999]

I tried scsi command

ioctl(3, (('s'<<8)|3), 0x100141F08)             = 0
ioctl(3, (('s'<<8)|0), 0x100141ED0)             = 0
ioctl(1, TCGETA, 0xFFFFFFFF7FFFDD4C)            = 0
fstat(1, 0xFFFFFFFF7FFFDCE0)                    = 0
Inquiry data: removable dev type 1h HP      Ultrium 1-SCSI  E38W
write(1, " I n q u i r y   d a t a".., 65)      = 65
close(3)                                        = 0

ioctl is the OS contacting the drive, I was hoping the scsi CBD would be clear, but alas not ...

However, we see that the inquiry data is sent straight back, no os or command intervention.

Next I tried mt (the filer mt should work the same )

ioctl(3, MNTIOC_GETDEVLIST, 0x00022864)         = 0
ioctl(3, MNTIOC_SETTAG, 0xFFBFFA80)             = 0
ioctl(1, TCGETA, 0xFFBFE99C)                    = 0
fstat64(1, 0xFFBFE8B8)                          = 0
stat64("/platform/SUNW,A70/lib/libc_psr.so.1", 0xFFBFDEA0) = 0
resolvepath("/platform/SUNW,A70/lib/libc_psr.so.1", "/platform/sun4u-us3/lib/libc_psr.so.1", 1023) = 37
open("/platform/SUNW,A70/lib/libc_psr.so.1", O_RDONLY) = 4
mmap(0x00010000, 6600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 4, 0) = 0xFF360000
munmap(0xFF362000, 4294965704)                  Err#22 EINVAL
close(4)                                        = 0
HP Ultrium LTO tape drive:
write(1, " H P   U l t r i u m   L".., 27)      = 27
   sense key(0x0)= No Additional Sense   residual= 0   retries= 0
write(1, "       s e n s e   k e y".., 66)      = 66
   file no= 0   block no= 0
write(1, "       f i l e   n o =  ".., 28)      = 28
_exit(0)

Pretty much identicle ...  Now I know that scsi_command only sends, scsi_commands, and mt seems to be the same (as I suspected), so I guess a bit more reassurance you have a drive issue and in no way related to the OS/ filer .

[Nicolai]

Interesting command Martin.

Could also be a robot issues. On almost all robots, there is a serial interface between drive and robot. If that serial interface breaks, weird things can happen.

[mph999]

True, you refer to the 'secret squirrel wire'

However, mt goes straight to the drive, no robot involved ...
 

[Nicolai]

True, but that interface cloud mess up the drives meaning of life so it think is a LTO2 drive.

if firmware revision is part of the inquery string, if would be worth checking if this was a LTO2 or LTO4 firmware.

[areznik]

If I remember right, when you zone a LTO drive to a filer and run a probe you get back a whole lot of paths some of which dont match the "real" density of the drive. I think it will show you all of the densities that the drive can work with in some way (including read only). If you run tpautoconf -probe <filername>, what's the full entry for nrst3a? Is there another one that fits LTO4 better?

[jim_dalton]

Thanks for info all. Hardware is being looked at. You are correct areznik:theres a whole list of devices and as far as tpautoconf is concerned nrst3a is correct, its lto4 norewind:

  Device "nrst3a" attributes=(0x4) RAW
    WORLD_WIDE_NAME=WWN[5:001:438016:002212]
    SERIAL_NUMBER=HUE3480BW3
    ELECTRICAL_NAME=wswhorchnbroc01:2.126
    DENSITY=LTO-4 1600GB cmp
    ALIAS 0=st3
 

This is why netbackup configures it into the stunit with the other lto4 cos they are the same. But when it actually comes to using it, it refuses. It seems to behave as nrst3m:

  Device "nrst3m" attributes=(0x4) RAW
    WORLD_WIDE_NAME=WWN[5:001:438016:002212]
    SERIAL_NUMBER=HUE3480BW3
    ELECTRICAL_NAME=wswhorchnbroc01:2.126
    DENSITY=LTO-2(ro)/3 4/800GB cmp
    ALIAS 0=st3

The drive path is 100% nrst3a in netbackup.

Jim

[mph999]

The other way to address this is to ask the filer vendor how their version of the 'mt' command works.

[mph999]

... cos if areznik is correct, which I am sure he is, that's a bit naughty of them as it changes the way mt works ...