All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.