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
next prev 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.