Open/INQUIRY fails on RESERVE'd tape device

Open/INQUIRY fails on RESERVE'd tape device

[Matthias Eble]

Hi list,

When a tape device is reserved with old reserve/release commands,
we see inquiry only works on the scsi generic device. For scsi tape devices
open() fails already:

# lsscsi -g | grep st15
[2:0:6:0]    tape    HP       Ultrium 5-SCSI   I5DZ  /dev/st15  /dev/sg17

# sg_vpd -vvv /dev/st15
  open /dev/st15 with flags=0x800
  error opening file: /dev/st15: Input/output error

# sg_vpd -vvv /dev/nst15
  open /dev/nst15 with flags=0x800
  error opening file: /dev/nst15: Input/output error

# sg_vpd -vvv /dev/sg17
open /dev/sg17 with flags=0x800
Supported VPD pages VPD page:
    inquiry cdb: 12 01 00 00 fc 00
      duration=2 ms
    inquiry: requested 252 bytes but got 22 bytes
   [PQual=0  Peripheral device type: tape]
  Supported VPD pages [sv]
  Unit serial number [sn]
  ...


So: should open() fail on a reserved tape device?
SPC2 states that INQUIRY should never conflict.
Or does that only apply to the generic device?
Okay, it doesn't conflict, but open fails. A SunOS st man page I found
states, INQUIRY shall be possible with reserved devices.

Of course the inquiry succeeds, after the reservation is being released.


Thanks in advance
Matthias

Re: Open/INQUIRY fails on RESERVE'd tape device

[kai.makisara]

Matthias Eble [psychotrahe@gmail.com] kirjoitti: 
> Hi list,
> 
> When a tape device is reserved with old reserve/release commands,
> we see inquiry only works on the scsi generic device. For scsi tape devices
> open() fails already:
> 
> # lsscsi -g | grep st15
> [2:0:6:0]    tape    HP       Ultrium 5-SCSI   I5DZ  /dev/st15  /dev/sg17
> 
> # sg_vpd -vvv /dev/st15
>   open /dev/st15 with flags=0x800
>   error opening file: /dev/st15: Input/output error
> 
> # sg_vpd -vvv /dev/nst15
>   open /dev/nst15 with flags=0x800
>   error opening file: /dev/nst15: Input/output error
> 
> # sg_vpd -vvv /dev/sg17
> open /dev/sg17 with flags=0x800
> Supported VPD pages VPD page:
>     inquiry cdb: 12 01 00 00 fc 00
>       duration=2 ms
>     inquiry: requested 252 bytes but got 22 bytes
>    [PQual=0  Peripheral device type: tape]
>   Supported VPD pages [sv]
>   Unit serial number [sn]
>   ...
> 
> 
> So: should open() fail on a reserved tape device?
> SPC2 states that INQUIRY should never conflict.
> Or does that only apply to the generic device?
> Okay, it doesn't conflict, but open fails. A SunOS st man page I found
> states, INQUIRY shall be possible with reserved devices.
> 
Opening a st device does more than INQUIRY (TEST_UNIT_READY, READ_BLOCK_LIMITS,
MODE_SENSE). Can this explain what you see?

Kai


-- 

Re: Open/INQUIRY fails on RESERVE'd tape device

[Jeremy Linton]

On 1/23/2014 4:02 PM, Matthias Eble wrote:

> So: should open() fail on a reserved tape device?

	Yes, this is expected behavior for tape devices, reserve 6/release is sometimes
used by backup applications in SAN environments as an arbitration mechanism
across multiple machines.

	Its not that the INQUIRY is failing, its that the st open sequence is doing a
reserve/TUR/etc during the open.

	If that fails then you can't open the drives sufficiently to send a inquiry via
pass-through. In some environments you can bypass that processing with
O_NDELAY/O_NONBLOCK. Or you just use the sg device which doesn't perform the
tape open processing that st does.

Re: Open/INQUIRY fails on RESERVE'd tape device

[Douglas Gilbert]

On 14-01-24 03:35 AM, kai.makisara@kolumbus.fi wrote:
> Matthias Eble [psychotrahe@gmail.com] kirjoitti:
>> Hi list,
>>
>> When a tape device is reserved with old reserve/release commands,
>> we see inquiry only works on the scsi generic device. For scsi tape devices
>> open() fails already:
>>
>> # lsscsi -g | grep st15
>> [2:0:6:0]    tape    HP       Ultrium 5-SCSI   I5DZ  /dev/st15  /dev/sg17
>>
>> # sg_vpd -vvv /dev/st15
>>   open /dev/st15 with flags=0x800
>>   error opening file: /dev/st15: Input/output error
>>
>> # sg_vpd -vvv /dev/nst15
>>   open /dev/nst15 with flags=0x800
>>   error opening file: /dev/nst15: Input/output error
>>
>> # sg_vpd -vvv /dev/sg17
>> open /dev/sg17 with flags=0x800
>> Supported VPD pages VPD page:
>>     inquiry cdb: 12 01 00 00 fc 00
>>       duration=2 ms
>>     inquiry: requested 252 bytes but got 22 bytes
>>    [PQual=0  Peripheral device type: tape]
>>   Supported VPD pages [sv]
>>   Unit serial number [sn]
>>   ...
>>
>>
>> So: should open() fail on a reserved tape device?
>> SPC2 states that INQUIRY should never conflict.
>> Or does that only apply to the generic device?
>> Okay, it doesn't conflict, but open fails. A SunOS st man page I found
>> states, INQUIRY shall be possible with reserved devices.
>>
> Opening a st device does more than INQUIRY (TEST_UNIT_READY, READ_BLOCK_LIMITS,
> MODE_SENSE). Can this explain what you see?

TEST UNIT READY is allowed in SPC-4 but there is a note
about it being disallowed (i.e. RESERVATION CONFLICT) in
SPC-2 and SPC-3. MODE SENSE conflicts with some types of
reservations and READ BLOCK LIMITS is allowed.

But EIO, arrrrr; that should be banned from the whole
storage subsystem. Either that or equate it to "I don't
have a clue why this failed". A Reservation Conflict is
a very useful piece of information that tells the user
twiddling knobs in sysfs ain't going to help.


And back to the original question; situations like these
are exactly why there needs to be pass-throughs (and
bsg should work as well as sg). A pass-through implements
a policy of "you asked for it, you got it, and with a
minimum of side effects".

Doug Gilbert

Re: Open/INQUIRY fails on RESERVE'd tape device

[Matthias Eble]

Hi all,

2014/1/24 Jeremy Linton <jlinton@tributary.com>:
> On 1/23/2014 4:02 PM, Matthias Eble wrote:
>> So: should open() fail on a reserved tape device?
>
>         Yes, this is expected behavior for tape devices, reserve 6/release is sometimes
> used by backup applications in SAN environments as an arbitration mechanism
> across multiple machines.

You hit the nail on the head. Problem is that our backup application
does inquiry on /dev/nst*,
which is broken when the same application uses RESERVE/RELEASE.

>         Its not that the INQUIRY is failing, its that the st open sequence is doing a
> reserve/TUR/etc during the open.

This is exactly what I am facing. I just thought that it might not be
OK to issue these commands with st_open. But I guess, there is no
right or wrong it's just implemented that way - so applications need
to deal with it and use a generic device.

>         If that fails then you can't open the drives sufficiently to send a inquiry via
> pass-through. In some environments you can bypass that processing with
> O_NDELAY/O_NONBLOCK. Or you just use the sg device which doesn't perform the
> tape open processing that st does.

I guess you mean operating systems with environments, as sg_vpd
also uses O_NONBLOCK, which doesn't help:
  open("/dev/st15", O_RDONLY|O_NONBLOCK)  = -1 EIO (Input/output error)

But as this behaviour has been there for long time, the backup vendor
needs to fix it IMO.

Thanks to all of you
Matthias