From: James Bottomley <James.Bottomley@SteelEye.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Morton <akpm@osdl.org>, Jens Axboe <axboe@suse.de>,
Kernel development list <linux-kernel@vger.kernel.org>,
SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 1/3] block layer: early detection of medium not present
Date: Thu, 08 Jun 2006 20:07:09 -0500 [thread overview]
Message-ID: <1149815229.3276.20.camel@mulgrave.il.steeleye.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0606061113040.9182-100000@iolanthe.rowland.org>
On Tue, 2006-06-06 at 11:26 -0400, Alan Stern wrote:
> When the block layer checks for new media in a drive, it uses a two-step
> procedure: First it checks for media change and then it revalidates the
> disk. When no medium is present the second step fails.
>
> However some drivers (such as the SCSI disk driver) are capable of
> detecting medium-not-present as part of the media-changed check. Doing so
> will reduce by a factor of 2 or more the amount of work done by tasks
> which, like hald, constantly poll empty drives.
>
> This patch (as694) changes the block layer core to make it recognize a
> -ENOMEDIUM error return from the media_changed method. A follow-on patch
> makes the sd driver return this code when no medium is present.
I'm not sure there's enough buy in to make this change yet ... our media
change handling is incredibly (and quite possibly far too) complex.
As documented in Documentation/cdrom/cdrom-standard.tex, the return
codes for media change are either 0 or 1.
Personally, I can't see a problem with overloading the true return to
have more information that the error codes provide, but before we do
this we need the buy in of the cdrom layer, since that's where this
handling came from, and we need to update the documents to reflect the
new behaviour ... someone also needs to consider what changes should be
made in the cdrom layer for this (and whether this is actually the
correct way to do this from the point of view of CDs).
James
next prev parent reply other threads:[~2006-06-09 3:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-06 15:26 Alan Stern
2006-06-09 1:07 ` James Bottomley [this message]
2006-06-09 14:17 ` Alan Stern
2006-06-09 14:19 ` Jens Axboe
2006-06-26 14:37 Alan Stern
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=1149815229.3276.20.camel@mulgrave.il.steeleye.com \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®