Re: 2.4.x end of tape handling error

Re: 2.4.x end of tape handling error

[Kevin Fenzi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Kai" == Kai Makisara <Kai.Makisara@kolumbus.fi> writes:

Kai> This discussion should really be moved to linux-scsi... 

ok.

Kai> 10 Feb 2003, Kevin Fenzi wrote:

>> Greetings.
>> 
>> 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.
>> 
Kai> What messages have they seen in the system log? Some messages
Kai> should be after this kind of error. It is difficult to see where
Kai> the problem is without any details. There have not been any
Kai> significant changes in EOM handling in st between the 2.4
Kai> kernels.

I have duplicated the problem with a dds2 drive I have here. 

Basically, they get back a EIO error instead of a ENOSPC error when
hitting the end of tape. 

>> 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.
>> 
>> Is this fixed in the latest 2.4.21-pres? How about in 2.5.x?
>> 
Kai> Don't know. EOM handling has worked with my test system (HP DDS
Kai> drives connected to a SYM53c896) with both 2.4 and 2.5 kernels. I
Kai> just reran the eom tests with 2.4.20 and 2.5.60 without problems.

My test system is very similar. 

HP DDS2 drive, on a SYM53c896. ;) 
Redhat 7.3 machine, running 2.4.18-24.7.x. 

To test I just used tar and tried to put more on the tape than would
fit. 

I got: 

...
write(3, "\305\230\240=:-v\t\237&\16\317\234+x\"N(\375\0\264\000"..., 10240) = -1 EIO (Input/output error)
write(2, "tar: ", 5)                    = 5
write(2, "/dev/nst0: Wrote only 0 of 10240"..., 38) = 38
write(2, "\n", 1)                       = 1
write(2, "tar: ", 5)                    = 5
write(2, "Error is not recoverable: exitin"..., 37) = 37
write(2, "\n", 1)                       = 1
munmap(0x4002e000, 4096)                = 0
_exit(2)                                = ?

I tried loading the driver with various options, in case it was a
buffering issue: 

modprobe st buffer_kbs=0 write_threshold_kbs=0 max_buffers=0 max_sg_segs=0

Any option I seemed to give it resulted in the same thing. 
I would be happy to test anything or provide you access to the box
with the tape drive on it. 
Will also try the 2.4.9-34 kernel that is supposed to not have this
issue. 

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+UaWe3imCezTjY0ERAt84AJ9JIzGEwm5H9Id4Tg4k0/o0fzZmgwCgk3zr
bP+qoI82jXtyMY7XU2YHjWU=
=4Z2L
-----END PGP SIGNATURE-----

Re: 2.4.x end of tape handling error

[Kevin Fenzi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Some more information on this problem discovered by Tim Jones
<tjones@tolisgroup.com>:

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-----

Re: 2.4.x end of tape handling error

[Kai Makisara]

On Mon, 24 Feb 2003, Kevin Fenzi wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Some more information on this problem discovered by Tim Jones
> <tjones@tolisgroup.com>:
>
> 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> 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

Re: 2.4.x end of tape handling error

[Kevin Fenzi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Kai" == Kai Makisara <Kai.Makisara@kolumbus.fi> writes:

Kai> On Mon, 24 Feb 2003, Kevin Fenzi wrote:

>> Some more information on this problem discovered by Tim Jones
>> <tjones@tolisgroup.com>:
>> 
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 ...):
>>
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.

>> 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-----