From: Jens Axboe <axboe@suse.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
Andrew Morton <akpm@osdl.org>,
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: Fri, 9 Jun 2006 16:19:16 +0200 [thread overview]
Message-ID: <20060609141916.GO31913@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0606091013470.16847-100000@netrider.rowland.org>
On Fri, Jun 09 2006, Alan Stern wrote:
> On Thu, 8 Jun 2006, James Bottomley wrote:
>
> > 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.
>
> I can change the documentation, if necessary. On the other hand, I don't
> want to embark on a global alteration of the media-change handling
> throughout the entire kernel! :-)
>
> > 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).
>
> Agreed. That's why I cc'ed Jens. Is there anyone else I should also ask
> about this change?
I'll be gone over the weekend, I can take a look next week.
--
Jens Axboe
next prev parent reply other threads:[~2006-06-09 14:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-06 15:26 [PATCH 1/3] block layer: early detection of medium not present Alan Stern
2006-06-09 1:07 ` James Bottomley
2006-06-09 14:17 ` Alan Stern
2006-06-09 14:19 ` Jens Axboe [this message]
-- strict thread matches above, loose matches on Subject: below --
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=20060609141916.GO31913@suse.de \
--to=axboe@suse.de \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@osdl.org \
--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 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.