Latest working kernel version: - This definitely used to work fine (no long delays) when we first installed the tape drive, which was back in July 2007. As we usually keep up to date with the latest kernels, I assume we were using 2.6.21 at the time but I don't have any logs to prove it. At the time the kernel was also 32-bit, though I hope that won't be an important difference. Earliest failing kernel version: - Unfortunately, I also have no idea when exactly it broke. It is definitely broken on at least 2.6.27 and 2.6.28. Distribution: Debian Lenny (x86_64) Hardware Environment: Xeon X3350, 8GB RAM, LSI53C1020A, HP LTO-3 Software Environment: mt (GNU cpio 2.9) Problem Description: mt is taking two minutes to return the status information for our tape drive when the drive is empty. It used to be almost immediate. I'm also fairly sure it used to give a different message as well, something with "OFFLINE" in it, rather than "rmtopen failed". Steps to reproduce: # time mt --file=/dev/nst0 status mt: /dev/nst0: rmtopen failed: No medium found real 2m0.709s user 0m0.003s sys 0m0.000s
Created attachment 19882 [details] Kernel config
This is an application bug: it opens the device without the O_NONBLOCK flag. The driver waits up to two minutes for the drive to become ready. You probably earlier had an mt that opens tape with O_NONBLOCK (from mt-st?).
Thanks, I think you are probably right. strace shows it (GNU mt) is using open("/dev/nst0", O_RDONLY). That would also explain why I remember something about the output being different. I remember now that I had to change my backup script - mt-st outputs to stdout and shows the status bits of the drive with "DR_OPEN" to indicate the tape isn't yet loaded, but exits with status 0. GNU mt prints it's error message to stderr and exits with status 1 when the tape isn't loaded.