Re: Open/INQUIRY fails on RESERVE'd tape device
Hi all,
2014/1/24 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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open/INQUIRY fails on RESERVE'd tape device
On 14-01-24 03:35 AM, kai.makis...@kolumbus.fi wrote: Matthias Eble [psychotr...@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]tapeHP 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, ar; 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open/INQUIRY fails on RESERVE'd tape device
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. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open/INQUIRY fails on RESERVE'd tape device
Matthias Eble [psychotr...@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]tapeHP 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 -- -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Open/INQUIRY fails on RESERVE'd tape device
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]tapeHP 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
