From: david@lang.hm
To: Chris Mason <chris.mason@oracle.com>
Cc: Ric Wheeler <rwheeler@redhat.com>, NeilBrown <neilb@suse.de>,
Nico Schottelius <nico-lkml-20110623@schottelius.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
Alasdair G Kergon <agk@redhat.com>
Subject: Re: Mis-Design of Btrfs?
Date: Fri, 15 Jul 2011 09:23:45 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1107150920180.3745@asgard.lang.hm> (raw)
In-Reply-To: <1310735821-sup-2589@shiny>
On Fri, 15 Jul 2011, Chris Mason wrote:
> Excerpts from Ric Wheeler's message of 2011-07-15 08:58:04 -0400:
>> On 07/15/2011 12:34 PM, Chris Mason wrote:
>
> By bubble up I mean that if you have multiple layers capable of doing
> retries, the lowest levels would retry first. Basically by the time we
> get an -EIO_ALREADY_RETRIED we know there's nothing that lower level can
> do to help.
the problem with doing this is that it can end up stalling the box for
significant amounts of time while all the retries happen.
we already see this happening today where a disk read failure is retried
multiple times by the disk, multiple times by the raid controller, and
then multiple times by Linux, resulting is multi-minute stalls when you
hit a disk error in some cases.
having the lower layers do the retries automatically runs the risk of
making this even worse.
This needs to be able to be throttled by some layer that can see the
entire picture (either by cutting off the retries after a number, after
some time, or by spacing out the retries to allow other queries to get in
and let the box do useful work in the meantime)
David Lang
next prev parent reply other threads:[~2011-07-15 16:24 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-23 10:53 Nico Schottelius
2011-06-27 6:46 ` NeilBrown
2011-06-29 9:29 ` Ric Wheeler
2011-07-14 5:56 ` NeilBrown
2011-07-14 6:02 ` Ric Wheeler
2011-07-14 6:38 ` NeilBrown
2011-07-14 6:57 ` Ric Wheeler
2011-07-15 2:32 ` Chris Mason
2011-07-15 4:58 ` david
2011-07-15 6:33 ` NeilBrown
2011-07-15 11:34 ` Chris Mason
2011-07-15 12:58 ` Ric Wheeler
2011-07-15 13:20 ` Chris Mason
2011-07-15 13:31 ` Ric Wheeler
2011-07-15 14:00 ` Chris Mason
2011-07-15 14:07 ` Hugo Mills
2011-07-15 14:24 ` Chris Mason
2011-07-15 14:47 ` Christian Aßfalg
2011-07-15 14:54 ` Hugo Mills
2011-07-15 15:12 ` Chris Mason
2011-07-15 16:23 ` david [this message]
2011-07-15 16:51 ` Ric Wheeler
2011-07-15 17:01 ` david
2011-07-15 17:23 ` Ric Wheeler
2011-07-15 13:55 ` Mike Snitzer
2011-07-15 16:03 ` david
2011-07-14 9:37 ` Jan Schmidt
2011-07-14 9:55 ` NeilBrown
2011-07-14 16:27 ` Goffredo Baroncelli
2011-07-14 16:55 ` Alasdair G Kergon
2011-07-14 19:50 ` John Stoffel
2011-07-14 20:48 ` david
2011-07-14 20:50 ` Erik Jensen
2011-07-14 6:59 ` Arne Jansen
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=alpine.DEB.2.02.1107150920180.3745@asgard.lang.hm \
--to=david@lang.hm \
--cc=agk@redhat.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=nico-lkml-20110623@schottelius.org \
--cc=rwheeler@redhat.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 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®