linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Davies <btrfs-list@steev.me.uk>
To: Anand Jain <anand.jain@oracle.com>
Cc: josef@toxicpanda.com, dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v6 5/5] btrfs: introduce new read_policy device
Date: Wed, 19 Feb 2020 12:18:16 +0000	[thread overview]
Message-ID: <ca5fe4b1232aadb3aa0d39b3b339dcbe@steev.me.uk> (raw)
In-Reply-To: <1582111766-8372-6-git-send-email-anand.jain@oracle.com>

On 2020-02-19 11:29, Anand Jain wrote:
> A new read policy 'device' is introduced with this patch, which when 
> set
> can pick only the device flagged as read_preferred for reading. This
> tunable is for the advance users and the testers, which can make sure 
> that
> reads are read from the device they prefer for chunks of type raid1,
> raid10, raid1c3 and raid1c4.
> 
> The default read policy is pid which can be changed to device as below.
> 
> $ pwd
> /sys/fs/btrfs/12345678-1234-1234-1234-123456789abc
> 
> $ cat read_policy; echo device > ./read_policy; cat read_policy
> [pid] device
> pid [device]
> 
> One or more devices which are favored for reading should set the flag
> read-preferred. In an example below a typical two disk raid1, devid1 is
> configured as read preferred.
> 
> $ echo 1 > devinfo/1/read_preferred
> $ cat devinfo/1/read_preferred; cat devinfo/2/read_preffered

Typo: should be read_preferred

> 1
> 0
> 
> So now when the file is read, the read IO would prefer device(s) with
> read_preferred flags for reading.
> 
> $ echo 3 > /proc/sys/vm/drop_caches; md5sum /btrfs/YkZI
> 
> Since the devid 1 (sdb) is our read preferred device, the reads are set
> to sdb only.
> $ iostat -zy 1 | egrep 'sdb|sdc' (from another terminal)
> sdb              50.00     40048.00         0.00      40048          0
> 
> $ echo 0 > ./devinfo/1/read_preferred; echo 1 >
> ./devinfo/2/read_preferred;
> 
> [ 3343.918658] BTRFS info (device sdb): reset read preferred on devid 1
> (1334)
> [ 3343.919876] BTRFS info (device sdb): set read preferred on devid 2
> (1334)
> 
> $ echo 3 > /proc/sys/vm/drop_caches; md5sum /btrfs/YkZI
> 
> Since now we changed the read preferred from devid 1 (sdb) to 2 (sdc),
> now all the read IO goes to sdc.
> 
> $ iostat -zy 1 | egrep 'sdb|sdc' (from another terminal)
> sdc              49.00     40048.00         0.00      40048          0
> 
> Whenever there isn't any read preferred device(s) or if more than one
> stripe is marked as read preferred device then this read policy shall
> use the stripe 0 for reading.

Should we consider the situation where more than one device is preferred 
(perhaps for a future patch) - e.g. devid1 is HDD, devid2 is SSD, devid3 
is SSD and data is RAID1C3?

Will there be a warning when this fallback to stripe 0 happens? Although 
I imagine that would either always display on mount before 
read_preferred is set or flood dmesg for every read.

Perhaps fallback to the %pid policy to give some form of balancing would 
be a better default?

-- 
Steven Davies

  reply	other threads:[~2020-02-19 12:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 11:29 [PATCH v6 0/5] readmirror feature (sysfs and in-memory only approach; with new read_policy device) Anand Jain
2020-02-19 11:29 ` [PATCH v6 1/5] btrfs: add btrfs_strmatch helper Anand Jain
2020-02-19 11:29 ` [PATCH v6 2/5] btrfs: create read policy framework Anand Jain
2020-02-19 11:29 ` [PATCH v6 3/5] btrfs: create read policy sysfs attribute, pid Anand Jain
2020-02-19 11:29 ` [PATCH v6 4/5] btrfs: introduce new device-state read_preferred Anand Jain
2020-02-19 11:29 ` [PATCH v6 5/5] btrfs: introduce new read_policy device Anand Jain
2020-02-19 12:18   ` Steven Davies [this message]
2020-02-20  3:54     ` 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=ca5fe4b1232aadb3aa0d39b3b339dcbe@steev.me.uk \
    --to=btrfs-list@steev.me.uk \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=josef@toxicpanda.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).