All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Davies <btrfs-list@steev.me.uk>
To: Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC 0/5] readmirror feature
Date: Thu, 21 Mar 2019 16:26:24 +0000	[thread overview]
Message-ID: <d7b84e2bcb9920d011e585391b70020e@steev.me.uk> (raw)
In-Reply-To: <1552989624-29577-1-git-send-email-anand.jain@oracle.com>

On 2019-03-19 10:00, Anand Jain wrote:
> RFC patch as of now, appreciate your comments. This patch set has
> been tested.
> 
> Function call chain  __btrfs_map_block()->find_live_mirror() uses
> thread pid to determine the %mirror_num when the mirror_num=0.
> 
> The pid based mirror_num extrapolation has following disadvantages
>  . A large single-process read IO will read only from one disk.
>  . In a worst scenario all processes read accessing the FS could have
>        either odd or even pid, the read IO gets skewed.
>  . There is no deterministic way of knowing/controlling which copy will
>        be used for reading.
>  . May see performance variations for a given set of multi process
>        workload ran at different times.
> 
> So we need other types of readmirror policies.
> 
> This patch introduces a framework so that we can add more policies, and
> converts the existing %pid into as a configurable parameter using the
> property. And also provides a transient readmirror mount option, so 
> that
> this property can be applied for the read io during mount and for
> readonly FS.

Is it possible to set this property at mkfs time?

>  For example:
>    btrfs property set <mnt> readmirror pid
>    btrfs property set <mnt> readmirror ""
>    btrfs property set <mnt> readmirror devid<n>
> 
>    mount -o readmirror=pid <mnt>
>    mount -o readmirror=devid<n> <mnt>

This is an edge case but should we be allowed to set more than one 
device as a read mirror in a 3+ device array? In theory there could be 
two fast disks and one slow disk where all stripes are guaranteed to be 
on at least one fast disk.

I'll test these patches out when I have some spare time over the next 
few weeks. Do you have a tree I can pull / what are the patches based 
on?

Way beyond this patch series, considering a 3+ device raid1 array with 
mixed fast and slow disks perhaps there could also be a write preference 
for disks to fill up the fast disks first.

Steven Davies

  parent reply	other threads:[~2019-03-21 16:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19 10:00 [PATCH RFC 0/5] readmirror feature Anand Jain
2019-03-19 10:00 ` [PATCH RFC 1/5] btrfs: add inode pointer to prop_handler::validate() Anand Jain
2019-03-19 10:00 ` [PATCH RFC 2/5] btrfs: add readmirror pid property Anand Jain
2019-03-19 10:00 ` [PATCH RFC 3/5] btrfs: add readmirror devid property Anand Jain
2019-03-19 10:00 ` [PATCH RFC 4/5] btrfs: add readmirror pid mount option Anand Jain
2019-03-19 10:00 ` [PATCH RFC 5/5] btrfs: add readmirror devid " Anand Jain
2019-03-19 10:02 ` [PATCH RFC 1/2] btrfs-progs: add helper to create xattr name Anand Jain
2019-03-19 10:02   ` [PATCH RFC 2/2] btrfs-progs: add readmirror policy Anand Jain
2019-03-21 16:26 ` Steven Davies [this message]
2019-03-21 18:26   ` [PATCH RFC 0/5] readmirror feature waxhead
2019-03-22  6:08   ` Anand Jain
2019-04-09 15:48 ` David Sterba
2019-04-12  9:02   ` Anand Jain

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=d7b84e2bcb9920d011e585391b70020e@steev.me.uk \
    --to=btrfs-list@steev.me.uk \
    --cc=anand.jain@oracle.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 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.