From: Jens Axboe <axboe@suse.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Steve Whitehouse <Steve@ChyGwyn.com>,
pavel@suse.cz, linux-kernel@vger.kernel.org
Subject: Re: NBD Cleanup patch and bugfix in ll_rw_blk.c
Date: Thu, 1 Mar 2001 01:07:51 +0100 [thread overview]
Message-ID: <20010301010751.Y21518@suse.de> (raw)
In-Reply-To: <200102282127.VAA20600@gw.chygwyn.com> <Pine.LNX.4.10.10102281525420.6380-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.10.10102281525420.6380-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Wed, Feb 28, 2001 at 03:29:34PM -0800
On Wed, Feb 28 2001, Linus Torvalds wrote:
> As far as I can tell, the patch will trigger only for a not-empty request
> list, where the elevator decides to put the new request at the head of the
> queue.
>
> Which is probably unlikely (and with the current elevator it might even be
> impossible). But it does not look impossible in theory. And I'd really
> prefer _not_ to have something that
> - looks completely bogus from a design standpoint
> - might be buggy under some rather unlikely circumstances
>
> Reading them together they become "might cause disk corruption in some
> really hard-to-trigger circumstances". No, thank you.
>
> Note that I suspect that all current drivers (or at least the common ones)
> have protection against being called multiple times, simply because 2.2.x
> used to do it. Which again means that you'd probably never see problems
> in practice. But that doesn't make it _right_.
I think most of the "we want to disable plugging" behaviour stems
from the way task queues behave. Once somebody starts a tq_disk
run, the list is fried and walked one by one. Both old loop
and nbd drop the io_request_lock and block, possibly waiting
for I/O to be done (at least the loop case, don't know about
ndb). But this I/O won't be done just because the target plug every
now and then just happens to be queued behind the nbd/loop one and a new
tq_disk run won't start it.
--
Jens Axboe
next prev parent reply other threads:[~2001-03-01 1:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-25 19:57 NBD Cleanup patch and bugfix in ll_rw_blk.c Steve Whitehouse
2001-02-25 20:55 ` Andrea Arcangeli
2001-02-25 20:59 ` Jens Axboe
2001-02-25 22:39 ` Russell King
2001-02-25 22:49 ` Jens Axboe
2001-02-25 23:02 ` Steve Whitehouse
2001-02-28 19:41 ` Linus Torvalds
2001-02-28 21:27 ` Steve Whitehouse
2001-02-28 21:37 ` Jens Axboe
2001-02-28 23:29 ` Linus Torvalds
2001-03-01 0:07 ` Jens Axboe [this message]
2001-03-01 3:14 ` Linus Torvalds
[not found] ` <200103010314.TAA06827@penguin.transmeta.com>
2001-03-01 13:39 ` Jens Axboe
2001-03-01 14:49 ` Jens Axboe
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=20010301010751.Y21518@suse.de \
--to=axboe@suse.de \
--cc=Steve@ChyGwyn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=torvalds@transmeta.com \
/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.