Tape "Device or Resource Busy" Same response always? WHY
 

Hi All,
I'm having a problem with a tape library and device. Setting up a backup system which runs with proprietary software and i'm not sure if the problem lies with them or with me and the server.

For some reason and they are un-able to work it out as well so far, their software isn't able to run backups to tape on this server. It keeps getting errors like Device or Resource busy?

The problem is:-
lsof -V /dev/st0 returns nothing is running
fuser /dev/st0 also can't see anything running.

tar -cfv /dev/st0 /etc
Works fine and can write to the device

tar -tfv /dev/st0
Works fine i can see the files i've just written

mt -f /dev/st0 status
Returns the fact it can see the tape and details about the tape so thats fine.

dd if=/dev/st0 of=/tmp/chips.dd bs=128k
dd: reading `/dev/st0': Device or resource busy
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.009054 seconds, 0.0 kB/s

Yet i also ran
"rmmod st"
to remove the devices from the kernel
and then "modprobe st"
to re-add the device again and still when doing the dd it says Device or Resource Busy.

Whats going on? Is it always meant to report Device or Resource Busy?

Cheers

Well, it's hard to say. All you've told us is you're using "a tape library", "a tape device", and "proprietary software", on "linux".
Kinda hard to diagnose a problem when you don't have any real information.....

If it was me, I'd get your hardware vendor and your backup software vendor together, and tell them to solve the problem. You're paying for both of these things, and if they can't figure it out, kick them to the curb. You shouldn't have to fix their problems for them...you're the customer.

Ok, if i said forget that its attached to a tape library, the O/S is SLES 10 tape drive LTO4 with LTO4 tapes (of course) and forget about the proprietary software as well.

Then what may cause the drive to always show as busy even though nothing is using the drive and the backup software at the time isn't running and the server is freshly re-booted?

I'm just wondering any inklings that anyone might have?

Regards

It doesn't make sense that tar works to read and write the tape and dd doesn't. Typically, if you use mt and tar to validate the functionality of a drive, you should be all set.

You're saying you reboot, you can tar to it and from it, but mt says it's busy and dd won't write to it. So, being systematic, just after you reboot, before you do anything, does mt say it is busy? When I'm testing or debugging tape devices/scripts/software, I typically use mt at every step to confirm the status, including the position.

Since you are on SLES 10, I'd be inclined to talk to Novell to find out how that could happen. I'd also carefully go over the installation and setup information that came with the tape library and drive and make sure it was done properly (both hardware and OS/driver configuration). I presume you have a front panel on the library where you can move tapes and load and unload them. What happens if you use that to force an unload and reload? The thing with tapes, too, is that you have to be patient. You're not killing any processes, assuming, for example, that the tar is working, and you just don't want to wait for it to finish? Also, you're using st0, not nst0, so it will rewind after each use. During that rewind it will still be busy, but it should be pretty fast.

Outside chance of hardware problems with the tape drive. But, since tar works, I think it's more likely something weird in the configuration or what you are doing.

Well, you can SAY to forget it's attached to a library, but IT can't forget it. The library manager will often time put a device into a 'locked' state, so that an operator can't eject a tape manually by accident. Which is why it's important to get the right drivers, and integrate them with your backup software, so it can talk to the library manager, and make it do what you want.

There are too many moving parts to say "forget about this one"...as choogendyk and I suggested, contact your vendors. You're on a supported OS, with support from your backup software vendor, and your hardware vendor.

Hi Guys

Thanks for your replies, both very interesting.

BTW - the mt commands i'm throwing at it aren't showing the device as busy but i'm only testing it with 'mt -f /dev/st0 status'
Its only the dd that shows the device is busy.

TBone - The library manager will often time put a device into a 'locked' state
Very interesting comment, so i've plugged in a spare tape drive external, and this has no problems with reading, writing and dd. I think you could be right along your path, just not sure why the library seems to lock the drives even after a reboot after manually moving the tape into the drive with the front panel on the media library.

I am in touch with the software vendor but its been a very slow process, so i thought i'd try my luck here as i couldn't find much on google related to my issue.

But thanks for your comments.
Regards

If you would provide the full information on what the tape library is and how you installed and configured it, then it might be possible for someone here to help. On the other hand, if you have technical support, use it. They'll ask you the same sorts of questions, but you'll probably be on the phone, so it'll go faster.

usually this message means "some other process has an open handle to that device still"
Though perhaps not in your case, since it works on some tape devices but not others?

fuser to the rescue
 

Hi,
This was making me crazy as well.
I use webmin filesystem backup to HP SCSI Ultrium LTO2 tape drive (/dev/st0) on red hat 5
as root:
# fuser -k /dev/st0
this will give a print out and put you back at prompt
#
# mt -f /dev/st0 status
this will now print out as expected and you can use device again!

I ran into this problem as well and, after some searching, I found a red hat issue that appears to be still unresolved that certain block sizes on dd cause the busy error.
https://access.redhat.com/solutions/444793 The last update is from 2015 and is marked as un-validated. I don't have access to the solution, so I can't see what it is. I was able to verify that if I changed bs to something else, like bs=256, dd does not give the error, but is unusable for me because it shoeshined the tape. I'm not sure what the valid range of block sizes is, but I tried 10M and that didn't work. I didn't investigate the source because I switched to the "buffer" command, which worked around the problem (package name 'buffer', and there is also a package called chiark-rwbuffer, which i downloaded, but didn't try using since buffer worked for me):

$ buffer < big101GBfile > /dev/st1

This is to a sdlt320 drive in uncompressed mode (since almost all the data has been already compressed by gzip and I don't believe this drive is smart enough to stop compressing when the compressed data increases in size) and it is NOT shoe-shining. At 16MB/s max sustained transfer, I'm expecting this file to finish in 108 minutes.

I have no idea why this issue has surfaced - I don't recall ever seeing it before, so it may be a regression. On the other hand, it does NOT appear to affect disk files, so perhaps some kind of issue particular to character devices...?