2.4.x end of tape handling error
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines
I have had reported from a client that they are having problems with backups that span more than one tape. Instead of getting an EOT error or EOM, they are getting an I/O error wich requires the driver to be unloaded and reloaded before the tape will work again.
http://www.linuxtapecert.org/ Says that the redhat 2.4.9-34 kernel is the last one that had proper EOT handling. Indeed, if they use the 2.4.9-34 kernel, the tape works properly. Thats not a very good solution however.
You neglected to mention what kind of tape it is. There are several types of tapes, served by a jigsaw puzzle of various drivers.
Quoted 1 line
Is this fixed in the latest 2.4.21-pres? How about in 2.5.x?
Why don't you try and verify it, then let us know? You may be the only guy in the world mad enough to use a tape with 2.5.x. Please share your valuable expirience.
-- Pete
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 11 lines
Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Pete" == Pete Zaitcev <[email protected]> writes:
I have had reported from a client that they are having problems with backups that span more than one tape. Instead of getting an EOT error or EOM, they are getting an I/O error wich requires the driver to be unloaded and reloaded before the tape will work again.
http://www.linuxtapecert.org/ Says that the redhat 2.4.9-34 kernel is the last one that had proper EOT handling. Indeed, if they use the 2.4.9-34 kernel, the tape works properly. Thats not a very good solution however.
Pete> You neglected to mention what kind of tape it is. There are Pete> several types of tapes, served by a jigsaw puzzle of various Pete> drivers.
The problem was reported to me on a LTO scsi drive, but they also said it happened on normal DAT drives. I am trying to get the exact model and such on that drive.
Quoted 1 line
Quoted 1 line
Is this fixed in the latest 2.4.21-pres? How about in 2.5.x?
Pete> Why don't you try and verify it, then let us know? You may be Pete> the only guy in the world mad enough to use a tape with 2.5.x. Pete> Please share your valuable expirience.
well, I have a HP dds2 drive here, so was happy to try and duplicate the problem. Starting with the 2.4.18-24.7.x-i686-smp redhat kernel.
In the interests of getting the problem to occur quickly, I partitioned the dds2 tape into 2 partitions, the second having only 10mb in it. That doesn't show the problem. I get ENOSPC as expected at the end of the small partition.
Without partitions if I write more than can fit on a dds2 tape, I get:
...
write(3, "r\342H\\5,\341\235\203\6\245`\264.C\303*\262\27qZ\343\305"..., 10240) = -1 EIO (Input/output error)write(2, "tar: ", 5) = 5write(2, "/dev/nst0: Wrote only 0 of 10240"..., 38) = 38write(2, "\n", 1) = 1write(2, "tar: ", 5) = 5write(2, "Error is not recoverable: exitin"..., 37) = 37
write(2, "\n", 1) = 1 munmap(0x4002e000, 4096) = 0 _exit(2) = ?
st0: Error with sense data: Info fld=0x28000, Current st09:00: sense key Medium Error Additional sense indicates Write error
st0: Error with sense data: Info fld=0x0, Current st09:00: sense key Medium Error Additional sense indicates Write error
st0: Error on write filemark.
st: Unloaded.
Sounds like it might be this issue:
I am trying another test with buffering off to see if that fixes it. Nope. Tried loading st with everything set to 0, no dice.
Pete> -- Pete
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQE+UZYf3imCezTjY0ERAtaeAJsH7cwVy8HCkzHoUH+x4D0t1En0NACeMR91 osNsXmVCPrvFCDRrUQ3NPPk=
=9ji/
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Some more information on this problem discovered by Tim Jones <[email protected]>:
Tim> Additional news.
Tim> This is actually related to the check sense bit not being Tim> propagated up to the ST driver. A simpler test (beats writing Tim> 40GB to a tape ...):
Tim> use a 2.2.19/20/21 or 22 kernel, or a 2.4.9-34 kernel Remove the Tim> tape from the tape device execute:
Tim> tar -cvvf /dev/nst0 /etc
Tim> You will receive a "No medium found" message
Tim> Replace the kernel with 2.4.11+ and repeat the tar write test. Tim> This time, you will receive a write failure.
Tim> This is caused by the check sense not being set and the ST driver Tim> sending up a EIO instead of the ENOMEDIUM.
So, it looks like this problem is _not_ in the st driver itself, but somewhere in the SCSI layer.
Anyone have any ideas how to better track it down?
Happy to run debug code/test cases here.
anyone?
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQE+WrCT3imCezTjY0ERAoNDAJ9kx5aTtxJZlxKL04IJmVTztvM5MQCeIuFS Y4RxoYEC619ckzSxXGIAlcM=
=A5/e
-----END PGP SIGNATURE-----
Quoted 13 lines · Kevin Fenzi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Some more information on this problem discovered by Tim Jones <[email protected]>:
Tim> Additional news.
Tim> This is actually related to the check sense bit not being Tim> propagated up to the ST driver. A simpler test (beats writing Tim> 40GB to a tape ...):
...
Quoted 10 lines
Tim> This is caused by the check sense not being set and the ST driver Tim> sending up a EIO instead of the ENOMEDIUM.
So, it looks like this problem is _not_ in the st driver itself, but somewhere in the SCSI layer.
Anyone have any ideas how to better track it down?
Happy to run debug code/test cases here.
If you enable debugging in the st driver, it prints on the console(dmesg)/system log the sense data it gets. (To enable debugging, edit the st source to '#define DEBUG 1' and recompile the kernel/module).
The st driver does in some cases behave too conservatively when the EOT early warning is found. This happens when operating in fixed block mode and only with some drives. The drives I use for testing behave in a different way and that is why I have not seen this problem (tracked down with debugging output from one kind user). I have a fix ready but testing will still take some time. This problem is not seen when asynchronous writes and driver buffering are disabled (as suggested in README.st when trying to rely on EOT detection).
Kai
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kai" == Kai Makisara <[email protected]> writes:
Quoted 3 lines · Kevin Fenzi
Quoted 3 lines
Some more information on this problem discovered by Tim Jones <[email protected]>:
Tim> Additional news.
Quoted 1 line
Quoted 1 line
Tim> This is actually related to the check sense bit not being Tim> propagated up to the ST driver. A simpler test (beats writing Tim> 40GB to a tape ...):
Quoted 1 line
Quoted 1 line
Kai> ...
Tim> This is caused by the check sense not being set and the ST driver Tim> sending up a EIO instead of the ENOMEDIUM.
Quoted 7 lines
Quoted 7 lines
So, it looks like this problem is _not_ in the st driver itself, but somewhere in the SCSI layer.
Anyone have any ideas how to better track it down?
Happy to run debug code/test cases here.
Kai> If you enable debugging in the st driver, it prints on the Kai> console(dmesg)/system log the sense data it gets. (To enable Kai> debugging, edit the st source to '#define DEBUG 1' and recompile Kai> the kernel/module).
Yeah, ok.
Kai> The st driver does in some cases behave too conservatively when Kai> the EOT early warning is found. This happens when operating in Kai> fixed block mode and only with some drives. The drives I use for Kai> testing behave in a different way and that is why I have not seen Kai> this problem (tracked down with debugging output from one kind Kai> user). I have a fix ready but testing will still take some Kai> time. This problem is not seen when asynchronous writes and Kai> driver buffering are disabled (as suggested in README.st when Kai> trying to rely on EOT detection).
Humm... I tried to disable async writes and buffering and still got the problem on my HP DDS2 drive.
Whats the correct procedure to disable both those?
mt -f /dev/nst0 stoptions buffer-writes 0
mt -f /dev/nst0 stoptions async-writes 0
I can repeat those tests to confirm, but I'm pretty sure I was seeing the problem even with those options set.
Would you like debug output from that case?
Kai> Kai
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQE+Y4em3imCezTjY0ERAsPOAJ4lSsrUfiDHPbdNQ+NcQxEy4w17sACdEkM8 EclBD42iXwpqsbiAJkeelEo=
=Uh2S
-----END PGP SIGNATURE-----