From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Jeff Mahoney <jeffm@suse.com>,
dsterba@suse.cz, Anand Jain <anand.jain@oracle.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 0/3] btrfs: add read mirror policy
Date: Thu, 17 May 2018 11:22:17 -0400 [thread overview]
Message-ID: <0e8be98d-61f4-0c67-f826-8cb5be3b7e47@gmail.com> (raw)
In-Reply-To: <9b32d248-6311-fa20-9d17-364310316412@suse.com>
On 2018-05-17 10:46, Jeff Mahoney wrote:
> On 5/16/18 6:35 PM, 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've seen a few alternate suggestions in the thread. I suppose the real
> question is: what and where is the intended persistence for this choice?
>
> A mount option gets it via fstab. How would a user be expected to set
> it consistently via ioctl on each mount? Properties could work, but
> there's more discussion needed there. Personally, I like the property
> idea since it could conceivably be used on a per-file basis.
For the specific proposed use case (the tests), it probably doesn't need
to be persistent beyond mount options.
However, this also allows for a trivial configuration using a slow
storage device to provide redundancy for a fast storage device of the
same size, which is potentially very useful for some people. In that
case, I can see most people who would be using it wanting it to follow
the filesystem regardless of what context it's being mounted in (for
example, it shouldn't need an extra option if mounted from a recovery
environment or if it's moved to another system).
Most of my reason for recommending properties is that filesystem level
properties appear to be the best thing BTRFS has to store per-volume
configuration that's supposed to stay with the volume, despite not
really being used for that even though there are quite a few mount
options that are logical candidates for this type of thing (for example,
the `ssd` options, `metadata_ratio`, and `max_inline` all make more
logical sense as a property of the volume, not the mount).
prev parent reply other threads:[~2018-05-17 15:30 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
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 [this message]
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=0e8be98d-61f4-0c67-f826-8cb5be3b7e47@gmail.com \
--to=ahferroin7@gmail.com \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=jeffm@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).