All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Bryant <nbryant@optonline.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: Suspending SCSI devices and buses
Date: Fri, 20 Aug 2004 08:30:28 -0400	[thread overview]
Message-ID: <4125EEE4.50102@optonline.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0408191647170.2106-100000@ida.rowland.org>

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.

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


Nathan

  parent reply	other threads:[~2004-08-20 12:30 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 [this message]
2004-08-20 13:35       ` Luben Tuikov
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=4125EEE4.50102@optonline.net \
    --to=nbryant@optonline.net \
    --cc=linux-scsi@vger.kernel.org \
    --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 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.