linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH RFC v2 0/2]  readmirror feature
Date: Mon, 26 Aug 2019 17:04:36 +0800	[thread overview]
Message-ID: <20190826090438.7044-1-anand.jain@oracle.com> (raw)

Function call chain  __btrfs_map_block()->find_live_mirror() uses
thread pid to determine the %mirror_num when the mirror_num=0.

This patch introduces a framework so that we can add policies to determine
the %mirror_num. And also adds the devid as the readmirror policy.

The new property is stored as an item in the device tree as show below.
    (BTRFS_READMIRROR_OBJECTID, BTRFS_PERSISTENT_ITEM_KEY, devid)

To be able to set and get this new property also introduces new ioctls
BTRFS_IOC_GET_READMIRROR and BTRFS_IOC_SET_READMIRROR. The ioctl argument
is defined as
        struct btrfs_ioctl_readmirror_args {
                __u64 type; /* RW */
                __u64 device_bitmap; /* RW */
        }

An usage example as follows:
        btrfs property set /btrfs readmirror devid:1,3
        btrfs property get /btrfs readmirror
          readmirror devid:1 3
        btrfs property set /btrfs readmirror ""
        btrfs property get /btrfs readmirror
          readmirror default

This patchset has been tested completely, however marked as RFC for the 
following reasons and comments on them (or any other) are appreciated as
usual.
 . The new objectid is defined as
      #define BTRFS_READMIRROR_OBJECTID -1ULL
   Need consent we are fine to use this value, and with this value it
   shall be placed just before the DEV_STATS_OBJECTID item which is more
   frequently used only during the device errors.

.  I am using a u64 bitmap to represent the devices id, so the max device
   id that we could represent is 63, its a kind of limitation which should
   be addressed before integration, I wonder if there is any suggestion?
   Kindly note that, multiple ioctls with each time representing a set of
   device(s) is not a choice because we need to make sure the readmirror
   changes happens in a commit transaction.

v1->RFC v2:
  . Property is stored as a dev-tree item instead of root inode extended
    attribute.
  . Rename BTRFS_DEV_STATE_READ_OPRIMIZED to BTRFS_DEV_STATE_READ_PREFERRED.
  . Changed format specifier from devid1,2,3.. to devid:1,2,3..

RFC->v1:
  Drops pid as one of the readmirror policy choices and as usual remains
  as default. And when the devid is reset the readmirror policy falls back
  to pid.
  Drops the mount -o readmirror idea, it can be added at a later point of
  time.
  Property now accepts more than 1 devid as readmirror device. As shown
  in the example above.

Anand Jain (1):
  btrfs: add readmirror framework and policy devid

 fs/btrfs/ctree.h                |   3 +
 fs/btrfs/disk-io.c              |   9 ++
 fs/btrfs/ioctl.c                | 108 ++++++++++++++++++++++++
 fs/btrfs/transaction.c          |   3 +
 fs/btrfs/volumes.c              | 145 +++++++++++++++++++++++++++++++-
 fs/btrfs/volumes.h              |   9 +-
 include/uapi/linux/btrfs.h      |  15 +++-
 include/uapi/linux/btrfs_tree.h |  11 +++
 8 files changed, 300 insertions(+), 3 deletions(-)

Anand Jain (1):
  btrfs_progs: add readmirror property and ioctl to set get

 ioctl.h | 14 +++++++++
 props.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 112 insertions(+)

             reply	other threads:[~2019-08-26  9:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-26  9:04 Anand Jain [this message]
2019-08-26  9:04 ` [PATCH RFC v2] btrfs: add readmirror framework and policy devid Anand Jain
2019-08-26  9:04 ` [PATCH RFC v2] btrfs-progs: add readmirror property and ioctl to set get readmirror Anand Jain
2019-08-29  3:39   ` [PATCH RFC v2.1] btrfs-progs: add readmirror property and ioctl to set get Anand Jain
2019-09-11 16:37 ` [PATCH RFC v2 0/2] readmirror feature David Sterba
2019-09-12  7:48   ` Anand Jain
2019-09-11 18:42 ` Josef Bacik
2019-09-11 19:13   ` Eli V
2019-09-11 19:16     ` Josef Bacik
2019-09-12  7:41       ` Anand Jain
2019-09-12  9:50         ` Josef Bacik
2019-09-12 10:00           ` Anand Jain
2019-09-12 10:03             ` Josef Bacik
2019-09-12 10:10               ` Anand Jain
2019-09-12 10:13                 ` Josef Bacik
2019-09-16  8:19                   ` Anand Jain
2019-09-24 14:27                     ` 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=20190826090438.7044-1-anand.jain@oracle.com \
    --to=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 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).