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
next prev 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.