New: mt takes two minutes to determine that the tape drive is empty
http://bugzilla.kernel.org/show_bug.cgi?id=12481
Summary: mt takes two minutes to determine that the tape drive is
empty
Product: SCSI Drivers
Version: 2.5
KernelVersion: 2.6.28
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]
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
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
[Bug 12481] mt takes two minutes to determine that the tape drive is empty
http://bugzilla.kernel.org/show_bug.cgi?id=12481
------- Comment #1 from [email protected] 2009-01-18 19:54 ------- Created an attachment (id=19882)
--> (http://bugzilla.kernel.org/attachment.cgi?id=19882&action=view)
Kernel config
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
[Bug 12481] mt takes two minutes to determine that the tape drive is empty
In reply to [email protected]http://bugzilla.kernel.org/show_bug.cgi?id=12481
------- Comment #2 from [email protected] 2009-01-19 11:10 ------- 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?).
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
[Bug 12481] mt takes two minutes to determine that the tape drive is empty
In reply to [email protected]http://bugzilla.kernel.org/show_bug.cgi?id=12481
[email protected] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |REJECTED
Resolution| |INVALID------- Comment #3 from [email protected] 2009-01-19 12:37 ------- 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.
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.