From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Anand Jain <anand.jain@oracle.com>,
dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 0/3] btrfs: add read mirror policy
Date: Thu, 17 May 2018 08:25:45 -0400 [thread overview]
Message-ID: <157ec7fa-e271-ed60-d22b-290db8122734@gmail.com> (raw)
In-Reply-To: <0ff3604a-4d67-4421-560f-40a87fe4001d@oracle.com>
On 2018-05-16 22:32, Anand Jain wrote:
>
>
> On 05/17/2018 06:35 AM, David Sterba wrote:
>> On Wed, May 16, 2018 at 06:03:56PM +0800, Anand Jain wrote:
>>> Not yet ready for the integration. As I need to introduce
>>> -o no_read_mirror_policy instead of -o read_mirror_policy=-<devid>
>>
>> Mount option is mostly likely not the right interface for setting such
>> options, as usual.
>
> I am ok to make it ioctl for the final. What do you think?
>
>
> But to reproduce the bug posted in
> Btrfs: fix the corruption by reading stale btree blocks
> It needs to be a mount option, as randomly the pid can
> still pick the disk specified in the mount option.
>
Personally, I'd vote for filesystem property (thus handled through the
standard `btrfs property` command) that can be overridden by a mount
option. With that approach, no new tool (or change to an existing tool)
would be needed, existing volumes could be converted to use it in a
backwards compatible manner (old kernels would just ignore the
property), and you could still have the behavior you want in tests (and
in theory it could easily be adapted to be a per-subvolume setting if we
ever get per-subvolume chunk profile support).
Of course, I'd actually like to see most of the mount options available
as filesystem level properties with the option to override through mount
options, but that's a lot more ambitious of an undertaking.
next prev parent reply other threads:[~2018-05-17 12:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-16 10:03 [PATCH v2 0/3] btrfs: add read mirror policy Anand Jain
2018-05-16 10:03 ` [PATCH v2 1/3] btrfs: add mount option read_mirror_policy Anand Jain
2018-05-16 10:03 ` [PATCH v2 2/3] btrfs: add read_mirror_policy parameter devid Anand Jain
2019-01-21 11:56 ` Steven Davies
2019-01-22 13:43 ` Anand Jain
2019-01-22 14:28 ` Steven Davies
2018-05-16 10:03 ` [PATCH v2 3/3] btrfs: read_mirror_policy ability to reset Anand Jain
2018-05-16 22:35 ` [PATCH v2 0/3] btrfs: add read mirror policy David Sterba
2018-05-17 2:32 ` Anand Jain
2018-05-17 12:25 ` Austin S. Hemmelgarn [this message]
2018-05-17 14:46 ` Jeff Mahoney
2018-05-18 8:06 ` Anand Jain
2018-05-18 12:36 ` Austin S. Hemmelgarn
2018-05-17 14:46 ` Jeff Mahoney
2018-05-17 15:22 ` Austin S. Hemmelgarn
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=157ec7fa-e271-ed60-d22b-290db8122734@gmail.com \
--to=ahferroin7@gmail.com \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--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).