From: Douglas Gilbert <dgilbert@interlog.com>
To: kai.makisara@kolumbus.fi, Matthias Eble <psychotrahe@gmail.com>,
linux-scsi@vger.kernel.org
Subject: Re: Open/INQUIRY fails on RESERVE'd tape device
Date: Fri, 24 Jan 2014 11:22:24 -0500 [thread overview]
Message-ID: <52E29340.3010401@interlog.com> (raw)
In-Reply-To: <11934060.3620421390552523314.JavaMail.kai.makisara@kolumbus.fi>
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
next prev parent reply other threads:[~2014-01-24 16:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 8:35 Open/INQUIRY fails on RESERVE'd tape device kai.makisara
2014-01-24 16:22 ` Douglas Gilbert [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-01-23 22:02 Matthias Eble
2014-01-24 15:36 ` Jeremy Linton
2014-01-24 21:48 ` Matthias Eble
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52E29340.3010401@interlog.com \
--to=dgilbert@interlog.com \
--cc=kai.makisara@kolumbus.fi \
--cc=linux-scsi@vger.kernel.org \
--cc=psychotrahe@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).