Re: Slow tape drive timeout

Re: Slow tape drive timeout

[Robert Hancock]

Kai Makisara wrote:
> On Tue, 1 Apr 2008, Carlo Nyto wrote:
> 
>> I am experiencing a two minute timeout open()ing a tape device when
>> there is no tape in the drive.
>>
>> open() with O_NONBLOCK succeeds immediately, however.
>>
> This is how open() is supposed to work according to standards (e.g., SUS) 
> if O_NONBLOCK is supported. (Well, actually open() should wait 
> indefinitely but the non-linux systems I tested had a timeout.) The linux 
> st driver was changed to comply with standards at 2.5.3. I.e., the 2.4 
> kernels did return immediately but the 2.6 kernels have always waited.
> 
>> The problem is that I am trying to set up Legato on a system that has
>> multiple tape drives. For certain common operations, Legato tries to
>> open() each tape drive multiple times. On a system with multiple tape
>> drives, this adds up to a significant amount of time wasted due to
>> this timeout.
>>
> You are not the only person who has noticed this. At work we had to 
> install a distribution using 2.4 kernel to our backup server in order to 
> use Legato ;-(
> 
> But this is a Legato problem, not a kernel problem.
> 
>> Solaris does not have this problem, and Legato support advises that
>> they are at the mercy of the operating system.
>>
> Solaris does return EIO. Either it does not support O_NONBLOCK or it is 
> not compliant with SUS.
> 
> Legato would not be so much "at the mercy of the operating system" if they 
> would write their software to work according to standards, not according 
> to some operating system.

Why is accessing the tape drive with no tape in it causing a timeout in 
the first place? I should think that would fail immediately with some 
"medium not present" error from the drive. Unless the drive has no 
mechanism to detect it, but that seems really retarded..

Re: Slow tape drive timeout

[Kai Makisara]

On Wed, 2 Apr 2008, Robert Hancock wrote:

> Kai Makisara wrote:
> > On Tue, 1 Apr 2008, Carlo Nyto wrote:
> > 
> > > I am experiencing a two minute timeout open()ing a tape device when
> > > there is no tape in the drive.
> > > 
> > > open() with O_NONBLOCK succeeds immediately, however.
> > > 
> > This is how open() is supposed to work according to standards (e.g., SUS) if
> > O_NONBLOCK is supported. (Well, actually open() should wait indefinitely but
> > the non-linux systems I tested had a timeout.) The linux st driver was
> > changed to comply with standards at 2.5.3. I.e., the 2.4 kernels did return
> > immediately but the 2.6 kernels have always waited.
> > 
...
> Why is accessing the tape drive with no tape in it causing a timeout in the
> first place? I should think that would fail immediately with some "medium not
> present" error from the drive. Unless the drive has no mechanism to detect it,
> but that seems really retarded..
> 
It does not seem retarded to me. If a program wants to just wait until the 
tape drive becomes ready (e.g., loads the tape), it can use the blocking 
open. This is simple. If a program wants to test the status, it uses 
non-blocking open. The behavior mandated by the standards provides 
alternatives. If O_NONBLOCK is not supported, the user program must 
implement the waiting logic if the program just wants to wait until the 
drive is ready before starting i/o.

-- 
Kai

Re: Slow tape drive timeout

[Robert Hancock]

Kai Makisara wrote:
> On Wed, 2 Apr 2008, Robert Hancock wrote:
> 
>> Kai Makisara wrote:
>>> On Tue, 1 Apr 2008, Carlo Nyto wrote:
>>>
>>>> I am experiencing a two minute timeout open()ing a tape device when
>>>> there is no tape in the drive.
>>>>
>>>> open() with O_NONBLOCK succeeds immediately, however.
>>>>
>>> This is how open() is supposed to work according to standards (e.g., SUS) if
>>> O_NONBLOCK is supported. (Well, actually open() should wait indefinitely but
>>> the non-linux systems I tested had a timeout.) The linux st driver was
>>> changed to comply with standards at 2.5.3. I.e., the 2.4 kernels did return
>>> immediately but the 2.6 kernels have always waited.
>>>
> ...
>> Why is accessing the tape drive with no tape in it causing a timeout in the
>> first place? I should think that would fail immediately with some "medium not
>> present" error from the drive. Unless the drive has no mechanism to detect it,
>> but that seems really retarded..
>>
> It does not seem retarded to me. If a program wants to just wait until the 
> tape drive becomes ready (e.g., loads the tape), it can use the blocking 
> open. This is simple. If a program wants to test the status, it uses 
> non-blocking open. The behavior mandated by the standards provides 
> alternatives. If O_NONBLOCK is not supported, the user program must 
> implement the waiting logic if the program just wants to wait until the 
> drive is ready before starting i/o.

This behavior is not consistent with any other removable storage device 
provided by Linux, however. If you try to open a CD-ROM device node when 
no disc is inserted, it doesn't block, it just gives you an error right 
away. Why should the tape drive behavior be different?

Re: Slow tape drive timeout

[Kai Makisara]

On Thu, 3 Apr 2008, Robert Hancock wrote:

> Kai Makisara wrote:
> > On Wed, 2 Apr 2008, Robert Hancock wrote:
> > 
> > > Kai Makisara wrote:
> > > > On Tue, 1 Apr 2008, Carlo Nyto wrote:
> > > > 
> > > > > I am experiencing a two minute timeout open()ing a tape device when
> > > > > there is no tape in the drive.
> > > > > 
> > > > > open() with O_NONBLOCK succeeds immediately, however.
> > > > > 
> > > > This is how open() is supposed to work according to standards (e.g.,
> > > > SUS) if
> > > > O_NONBLOCK is supported. (Well, actually open() should wait indefinitely
> > > > but
> > > > the non-linux systems I tested had a timeout.) The linux st driver was
> > > > changed to comply with standards at 2.5.3. I.e., the 2.4 kernels did
> > > > return
> > > > immediately but the 2.6 kernels have always waited.
> > > > 
> > ...
> > > Why is accessing the tape drive with no tape in it causing a timeout in
> > > the
> > > first place? I should think that would fail immediately with some "medium
> > > not
> > > present" error from the drive. Unless the drive has no mechanism to detect
> > > it,
> > > but that seems really retarded..
> > > 
> > It does not seem retarded to me. If a program wants to just wait until the
> > tape drive becomes ready (e.g., loads the tape), it can use the blocking
> > open. This is simple. If a program wants to test the status, it uses
> > non-blocking open. The behavior mandated by the standards provides
> > alternatives. If O_NONBLOCK is not supported, the user program must
> > implement the waiting logic if the program just wants to wait until the
> > drive is ready before starting i/o.
> 
> This behavior is not consistent with any other removable storage device
> provided by Linux, however. If you try to open a CD-ROM device node when no
> disc is inserted, it doesn't block, it just gives you an error right away. Why
> should the tape drive behavior be different?

The tape driver supports O_NONBLOCK, the cdrom and disk drivers don't. The 
tape and disk drivers are otherwise so different (tape is character 
device, disks block devices) that I don't think it is a problem if the 
tape drive supports more features than the disk drivers.

I looked at my emails from 2001 when support for O_NONBLOCK was 
introduced. The reasons for this where standards (as mentioned already) 
and that some applications required this feature. So, it was not added 
just for fun.

-- 
Kai

Re: Slow tape drive timeout

[Bodo Eggert]

Kai Makisara <Kai.Makisara@kolumbus.fi> wrote:
> On Wed, 2 Apr 2008, Robert Hancock wrote:

>> Why is accessing the tape drive with no tape in it causing a timeout in the
>> first place? I should think that would fail immediately with some "medium not
>> present" error from the drive. Unless the drive has no mechanism to detect
>> it, but that seems really retarded..
>> 
> It does not seem retarded to me. If a program wants to just wait until the
> tape drive becomes ready (e.g., loads the tape), it can use the blocking
> open. This is simple.

This would be simple, if there were no timeout. Having the timeout, the program
must loop anyway.

> If a program wants to test the status, it uses 
> non-blocking open. The behavior mandated by the standards provides
> alternatives. If O_NONBLOCK is not supported, the user program must
> implement the waiting logic if the program just wants to wait until the
> drive is ready before starting i/o.

Therfore a portable program SHOULD implement a waiting logic that won't burn
the CPU if there is no tape in the drive.

It's still sane to allow waiting for media change, but this applies to any
removable media.

Slow tape drive timeout

[Carlo Nyto]

I am experiencing a two minute timeout open()ing a tape device when
there is no tape in the drive.

open() with O_NONBLOCK succeeds immediately, however.

The problem is that I am trying to set up Legato on a system that has
multiple tape drives. For certain common operations, Legato tries to
open() each tape drive multiple times. On a system with multiple tape
drives, this adds up to a significant amount of time wasted due to
this timeout.

Solaris does not have this problem, and Legato support advises that
they are at the mercy of the operating system.

Changing the timeout with e.g. "mt -f /dev/nst0 sttimeout 15" does not
change the timeout to 15 seconds, it is still exactly 2 minutes.

This happens with kernel 2.6.24.4, as well as RedHat's 2.6.9-67.

Here is a snippet of strace -T -tt output:

15:56:18.688392 open("/dev/nst0", O_RDONLY) = -1 ENOMEDIUM (No medium
found) <120.480482>

In this case, the tape device is a Quantum DLT-S4 connected to with an
Emulex FC card, via a Fibre Channel SAN.

Any help would be appreciated. Thanks.

Re: Slow tape drive timeout

[Kai Makisara]

On Tue, 1 Apr 2008, Carlo Nyto wrote:

> I am experiencing a two minute timeout open()ing a tape device when
> there is no tape in the drive.
> 
> open() with O_NONBLOCK succeeds immediately, however.
> 
This is how open() is supposed to work according to standards (e.g., SUS) 
if O_NONBLOCK is supported. (Well, actually open() should wait 
indefinitely but the non-linux systems I tested had a timeout.) The linux 
st driver was changed to comply with standards at 2.5.3. I.e., the 2.4 
kernels did return immediately but the 2.6 kernels have always waited.

> The problem is that I am trying to set up Legato on a system that has
> multiple tape drives. For certain common operations, Legato tries to
> open() each tape drive multiple times. On a system with multiple tape
> drives, this adds up to a significant amount of time wasted due to
> this timeout.
> 
You are not the only person who has noticed this. At work we had to 
install a distribution using 2.4 kernel to our backup server in order to 
use Legato ;-(

But this is a Legato problem, not a kernel problem.

> Solaris does not have this problem, and Legato support advises that
> they are at the mercy of the operating system.
> 
Solaris does return EIO. Either it does not support O_NONBLOCK or it is 
not compliant with SUS.

Legato would not be so much "at the mercy of the operating system" if they 
would write their software to work according to standards, not according 
to some operating system.

-- 
Kai