From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Nathan Bryant <nbryant@optonline.net>
Cc: Alan Stern <stern@rowland.harvard.edu>,
SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: Suspending SCSI devices and buses
Date: Fri, 20 Aug 2004 09:35:55 -0400 [thread overview]
Message-ID: <4125FE3B.7070608@adaptec.com> (raw)
In-Reply-To: <4125EEE4.50102@optonline.net>
Nathan Bryant wrote:
> Alan Stern wrote:
>
> >Thanks. Looking at your patch, I have a question. It doesn't look like
> >the resume path is careful to check for Unit Attention with Power On or
> >Medium May Have Changed sense. What happens if somebody changes the
> >medium while the drive is suspended? Or am I missing something?
> >
> You're not missing anything. :(
>
> Thanks for the feedback, looks like you've found a real problem with the
> patch: that is, due to the unconditonal spinup call on resume, we clear
> any UNIT ATTENTION state before any of the upper layers ever see it, so
> nobody will notice a possible media change.
If UA exists for the initiator port, commands other INQURY, REPORT LUNS
and REPORT SENSE, get terminated and UA reported (CHECK CONDITION with
sense data). So spinup (TUR + START STOP UNIT) could report the media
change (on TUR).
>
> Unfortunately, I think that the current media change detection code in
> the Linux kernel can not distinguish power-on events from media change
> events. I'm not sure doing so is even possible for SCSI devices.
It would really depend on the device (if it kept state over power failures).
But it is true that the code should be able to handle it. (Also UAs could
be queued by the device server--the code could use this.)
> (Comments on that?) Proposed solutions:
>
> Approach #1:
> * Continue to do the unconditional spinup, but only for devices that are
> already mounted.
> This may miss some media change events, but if we really can't
> distinguish power-on from media change, maybe that's somebody else's
> problem if the device was already mounted. (Changing mounted media is
> the user's fault.)
>
> (Hmm, what about devices that are opened for read/write but not mounted?)
>
> Approach #2:
> * Test for UNIT_ATTENTION before spinning up and report this as a media
> change.
> Safer, but may report "false positive" media change events if the device
> was only powered down/up.
UA can tell you when "removable medium may have changed" (SAM3r13, 5.9.7, b)
and "LU inventory has been changed" (same, g).
But it is true -- I can imagine media being changed without the device
knowing it (old enclosure + power off + screw-driver :-) ).
Luben
next prev parent reply other threads:[~2004-08-20 13:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-18 20:36 Suspending SCSI devices and buses Alan Stern
2004-08-18 20:42 ` Christoph Hellwig
2004-08-18 20:49 ` Nathan Bryant
2004-08-19 21:05 ` Alan Stern
2004-08-19 21:20 ` Nathan Bryant
2004-08-20 12:30 ` Nathan Bryant
2004-08-20 13:35 ` Luben Tuikov [this message]
2004-08-20 14:33 ` Nathan Bryant
2004-08-20 15:08 ` Alan Stern
2004-08-20 15:53 ` Nathan Bryant
2004-08-20 16:43 ` Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2004-08-20 20:49 Pat LaVarre
2004-08-20 21:38 ` Nathan Bryant
2004-08-20 22:06 ` Pat LaVarre
2004-08-20 22:32 ` Nathan Bryant
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=4125FE3B.7070608@adaptec.com \
--to=luben_tuikov@adaptec.com \
--cc=linux-scsi@vger.kernel.org \
--cc=nbryant@optonline.net \
--cc=stern@rowland.harvard.edu \
/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