From: Arne Jansen <sensille@gmx.net>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: don't add both copies of DUP to reada extent tree
Date: Sat, 25 Feb 2012 14:09:50 +0100 [thread overview]
Message-ID: <4F48DD9E.7030200@gmx.net> (raw)
In-Reply-To: <pan.2012.02.25.08.33.39@cox.net>
On 02/25/12 09:33, Duncan wrote:
> Arne Jansen posted on Sat, 25 Feb 2012 09:09:47 +0100 as excerpted:
>
>> Normally when there are 2 copies of a block, we add both to the reada
>> extent tree and prefetch only the one that is easier to reach.
>> This way we can better utilize multiple devices.
>> In case of DUP this makes no sense as both copies reside on the same
>> device.
>
> I'm not a coder and thus can't really read the code to know, but wouldn't
> the same easier-to-reach logic apply there, only to seeking? One of the
> DUPs should be easier to reach (less seeking) than the other.
>
Well, the commit message is kind of sloppy. The reada code collects
as many blocks near to each other and reads them sequentially. From
time to time it moves on to the next filled zone. That's when a longer
seek happens. It doesn't try to keep these longer seeks as short as
possible, instead it picks a zone on the disk where it has many
blocks to read.
As both parts of a DUP are filled equally, it doesn't matter which one
it picks, so it is sufficient to keep track of only one half of the
mirror. Things change in a multi-disk setup, as the heads can move
independently.
(this explanation is kind of sloppy, too)
-Arne
next prev parent reply other threads:[~2012-02-25 13:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-25 8:09 [PATCH] btrfs: don't add both copies of DUP to reada extent tree Arne Jansen
2012-02-25 8:33 ` Duncan
2012-02-25 13:09 ` Arne Jansen [this message]
2012-02-25 22:03 ` Duncan
2012-03-15 15:00 ` Andrea Gelmini
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=4F48DD9E.7030200@gmx.net \
--to=sensille@gmx.net \
--cc=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).