linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Nikolay Borisov <nborisov@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/2] btrfs: add read_mirror_policy parameter devid
Date: Wed, 31 Jan 2018 17:28:26 +0800	[thread overview]
Message-ID: <7a21d5f0-b7f0-9da6-22b6-b45976d6ab40@oracle.com> (raw)
In-Reply-To: <f4772f0c-c53e-c859-7da9-b2181a3507c1@suse.com>



On 01/31/2018 04:38 PM, Nikolay Borisov wrote:
> 
> 
> On 30.01.2018 08:30, Anand Jain wrote:
>> Adds the mount option:
>>    mount -o read_mirror_policy=<devid>
>>
>> To set the devid of the device which should be used for read. That
>> means all the normal reads will go to that particular device only.
>>
>> This also helps testing and gives a better control for the test
>> scripts including mount context reads.
> 
> Some code comments below. OTOH, does such policy really make sense, what
> happens if the selected device fails, will the other mirror be retried?

  Everything as usual, read_mirror_policy=devid just lets the user to
  specify his read optimized disk, so that we don't depend on the pid
  to pick a stripe mirrored disk, and instead we would pick as suggested
  by the user, and if that disk fails then we go back to the other mirror
  which may not be the read optimized disk as we have no other choice.

> If the answer to the previous question is positive then why do we really
> care which device is going to be tried first?

  It matters.
    - If you are reading from both disks alternatively, then it
      duplicates the LUN cache on the storage.
    - Some disks are read-optimized and using that for reading and going
      back to the other disk only when this disk fails provides a better
      overall read performance.

::
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index 39ba59832f38..478623e6e074 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -5270,6 +5270,16 @@ static int find_live_mirror(struct btrfs_fs_info *fs_info,
>>   		num = map->num_stripes;
>>   
>>   	switch(fs_info->read_mirror_policy) {
>> +	case BTRFS_READ_MIRROR_BY_DEV:
>> +		optimal = first;
>> +		if (test_bit(BTRFS_DEV_STATE_READ_MIRROR,
>> +			     &map->stripes[optimal].dev->dev_state))
>> +			break;
>> +		if (test_bit(BTRFS_DEV_STATE_READ_MIRROR,
>> +			     &map->stripes[++optimal].dev->dev_state))
>> +			break;
>> +		optimal = first;
> 
> you set optimal 2 times, the second one seems redundant.

  No actually. When both the disks containing the stripe does not
  have the BTRFS_DEV_STATE_READ_MIRROR, then I would just want to
  use first found stripe.

> Alongside this
> patch it makes sense to also send a patch to btrfs(5) man page
> describing the mount option + description of each implemented allocation
> policy.

  Yep. Will do.

> Another thing which I don't see here is how you are handling the case
> when you have more than 2 devices in the RAID1 case. As it stands
> currently you assume there are two devices and first test device 0 and
> then device 1 and completely ignore any other devices.

  Not really. That part is already handled by the extent mapping.
  As the number of stripe for raid1 is two, the extent mapping will
  manage put related two devices of this stripe.

Thanks, Anand

  reply	other threads:[~2018-01-31  9:27 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 [this message]
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
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=7a21d5f0-b7f0-9da6-22b6-b45976d6ab40@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.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;
as well as URLs for NNTP newsgroup(s).