From: David Sterba <dsterba@suse.cz>
To: Anand Jain <anand.jain@oracle.com>
Cc: dsterba@suse.cz, dsterba@suse.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v7 rebased 0/5] readmirror feature (sysfs and in-memory only approach; with new read_policy device)
Date: Fri, 22 May 2020 15:46:56 +0200 [thread overview]
Message-ID: <20200522134656.GL18421@twin.jikos.cz> (raw)
In-Reply-To: <c61a44bf-04ab-01a0-3fbe-4d5970827085@oracle.com>
On Tue, May 19, 2020 at 06:02:32PM +0800, Anand Jain wrote:
> On 16/5/20 3:58 am, David Sterba wrote:
> > On Thu, Apr 30, 2020 at 05:02:27PM +0800, Anand Jain wrote:
> >> I am not sure if this will be integrated in 5.8 and worth the time to
> >> rebase. Kindly suggest.
> >
> > The preparatory work is ok, but the actual mirror selection policy
> > addresses a usecase that I think is not the one most users are
> > interested in. Devices of vastly different performance capabilities like
> > rotational disks vs nvme vs ssd vs network block devices in one
> > filesystem are not something commonly found.
> >
> > What we really need is a saner balancing mechanism than pid-based, that
> > is also going to be used any time there are more devices from the same
> > speed class for the fast devices too.
>
> There are two things here, the read_policy framework in the preparatory
> patches and a new balancing or read_policy, device.
>
> > So, no the patchset is not on track for a merge without the improved
> > default balancing.
>
> It can be worked on top of the preparatory read_policy framework?
Yes.
> This patchset does not change any default read_policy (or balancing)
> which is pid as of now. Working on a default read_policy/balancing
> was out of the scope of this patchset.
>
> > The preferred device for reads can be one of the
> > policies, I understand the usecase and have not problem with that
> > although wouldn't probably have use for it.
>
> For us, read_policy:device helps to reproduce raid1 data corruption
> https://patchwork.kernel.org/patch/11475417/
> And xfstests btrfs/14[0-3] can be improved so that the reads directly
> go the device of the choice, instead of waiting for the odd/even pid.
>
> Common configuration won't need this, advance configurations assembled
> with heterogeneous devices where read performance is more critical than
> write will find read_policy:device useful.
Yes that's the usecase and the possibility to make more targeted tests
is also good, but that still means the feature is half-baked and missing
the main part. If it was out of scope, ok fair, but I don't want to
merge it at that state. It would be embarassing to announce mirror
selection followed by "ah no it's useless for anything than this special
usecase".
next prev parent reply other threads:[~2020-05-22 13:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 11:51 [PATCH v7 rebased 0/5] readmirror feature (sysfs and in-memory only approach; with new read_policy device) Anand Jain
2020-04-06 11:51 ` [PATCH v7 1/5] btrfs: add btrfs_strmatch helper Anand Jain
2020-04-06 11:51 ` [PATCH v7 2/5] btrfs: create read policy framework Anand Jain
2020-04-06 11:51 ` [PATCH v7 3/5] btrfs: create read policy sysfs attribute, pid Anand Jain
2020-05-19 10:07 ` Johannes Thumshirn
2020-05-20 8:54 ` Anand Jain
2020-05-20 8:55 ` Johannes Thumshirn
2020-04-06 11:51 ` [PATCH v7 4/5] btrfs: introduce new device-state read_preferred Anand Jain
2020-04-06 11:51 ` [PATCH v7 5/5] btrfs: introduce new read_policy device Anand Jain
2020-04-30 9:02 ` [PATCH v7 rebased 0/5] readmirror feature (sysfs and in-memory only approach; with new read_policy device) Anand Jain
2020-05-15 19:58 ` David Sterba
2020-05-19 10:02 ` Anand Jain
2020-05-22 13:46 ` David Sterba [this message]
2020-05-26 7:23 ` Anand Jain
2020-06-01 15:07 ` David Sterba
2020-05-22 19:15 ` Steven Davies
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=20200522134656.GL18421@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.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).