linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



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