linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Peter Becker <floyd.net@gmail.com>, Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 0/2] Policy to balance read across mirrored devices
Date: Wed, 31 Jan 2018 11:11:57 -0500	[thread overview]
Message-ID: <8a2e10b7-7476-f655-f3b8-aeb191049104@gmail.com> (raw)
In-Reply-To: <CAEtw4r1gZCexSZnq_G43d55MwpXN0s-vS2Uyn2M9N2Cvi15QYA@mail.gmail.com>

On 2018-01-31 09:52, Peter Becker wrote:
> This is all clear. My question referes to "use the lower devid disk
> containing the stripe"
> 
> 2018-01-31 10:01 GMT+01:00 Anand Jain <anand.jain@oracle.com>:
>>   When a stripe is not present on the read optimized disk it will just
>>   use the lower devid disk containing the stripe (instead of failing back
>>   to the pid based random disk).
> 
> Use only one disk (the disk with the lowest devid that containing the
> stripe) as fallback should be not a good option imho.
> Instead of it should still be used the pid as fallback to distribute
> the workload among all available drives.
> 
> [stripe to use] = [preffer stripes present on read_mirror_policy
> devids] > [fallback to pid % stripe count]
> 
> Perhaps I'm not be able to express myself in English or did I misunderstand you?
Unless I'm seriously misunderstanding the commit messages, the primary 
purpose of having this as an option at all is for testing.  The fact 
that it happens to allow semantics similar to MD's write-mostly flag 
when dealing with a 2-device raid1 profile is just a bonus.

  reply	other threads:[~2018-01-31 16:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30  6:30 [PATCH 0/2] Policy to balance read across mirrored devices Anand Jain
2018-01-30  6:30 ` [PATCH 1/2] btrfs: add mount option read_mirror_policy Anand Jain
2018-01-31  8:06   ` Nikolay Borisov
2018-01-31  9:06     ` Anand Jain
2018-01-30  6:30 ` [PATCH 2/2] btrfs: add read_mirror_policy parameter devid Anand Jain
2018-01-31  8:38   ` Nikolay Borisov
2018-01-31  9:28     ` Anand Jain
2018-01-31  9:54       ` Nikolay Borisov
2018-01-31 13:38         ` Anand Jain
2018-01-31 13:42           ` Nikolay Borisov
2018-01-31 14:36             ` Anand Jain
2018-02-01  5:26               ` Edmund Nadolski
2018-02-01  8:12                 ` Anand Jain
2018-02-01 23:46                   ` Edmund Nadolski
2018-02-02 12:36                     ` Austin S. Hemmelgarn
2018-02-05  7:21                       ` Anand Jain
2018-01-31  7:51 ` [PATCH 0/2] Policy to balance read across mirrored devices Peter Becker
2018-01-31  9:01   ` Anand Jain
2018-01-31 10:47     ` Peter Becker
2018-01-31 14:26       ` Anand Jain
2018-01-31 14:52         ` Peter Becker
2018-01-31 16:11           ` Austin S. Hemmelgarn [this message]
2018-01-31 16:40             ` Peter Becker

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=8a2e10b7-7476-f655-f3b8-aeb191049104@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=anand.jain@oracle.com \
    --cc=floyd.net@gmail.com \
    --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).