On 22/5/20 9:46 pm, David Sterba wrote:
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".
I didn't realize the need for default policy is prioritized before this
patch set.
Potential default read policy is interesting, looking into it.
Thanks, Anand
