From: Anand Jain <anand.jain@oracle.com>
To: sam tygier <samtygier@yahoo.co.uk>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] Btrfs: Check metadata redundancy on balance
Date: Mon, 05 Oct 2015 10:33:13 +0800 [thread overview]
Message-ID: <5611E169.1060902@oracle.com> (raw)
In-Reply-To: <muotgb$4mf$1@ger.gmane.org>
Sam,
On 10/03/2015 11:50 PM, sam tygier wrote:
> Currently BTRFS allows you to make bad choices of data and
> metadata levels. For example -d raid1 -m raid0 means you can
> only use half your total disk space, but will loose everything
> if 1 disk fails. It should give a warning in these cases.
Nice test case. however the way we calculate the impact of
lost device would be per chunk, as in the upcoming patch -set.
PATCH 1/5] btrfs: Introduce a new function to check if all chunks a
OK for degraded mount
The above patch-set should catch the bug here. Would you be able to
confirm if this patch is still needed Or apply your patch on top of
it ?
Thanks, Anand
> This patch is a follow up to
> [PATCH v2] btrfs-progs: check metadata redundancy
> in order to cover the case of using balance to convert to such
> a set of raid levels.
>
> A simple example to hit this is to create a single device fs,
> which will default to single:dup, then to add a second device and
> attempt to convert to raid1 with the command
> btrfs balance start -dconvert=raid1 /mnt
> this will result in a filesystem with raid1:dup, which will not
> survive the loss of one drive. I personally don't see why the tools
> should allow this, but in the previous thread a warning was
> considered sufficient.
>
> Changes in v2
> Use btrfs_get_num_tolerated_disk_barrier_failures()
>
> Signed-off-by: Sam Tygier <samtygier@yahoo.co.uk>
>
> From: Sam Tygier <samtygier@yahoo.co.uk>
> Date: Sat, 3 Oct 2015 16:43:48 +0100
> Subject: [PATCH] Btrfs: Check metadata redundancy on balance
>
> When converting a filesystem via balance check that metadata mode
> is at least as redundant as the data mode. For example give warning
> when:
> -dconvert=raid1 -mconvert=single
> ---
> fs/btrfs/volumes.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 6fc73586..40247e9 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -3584,6 +3584,12 @@ int btrfs_balance(struct btrfs_balance_control *bctl,
> }
> } while (read_seqretry(&fs_info->profiles_lock, seq));
>
> + if (btrfs_get_num_tolerated_disk_barrier_failures(bctl->meta.target) <
> + btrfs_get_num_tolerated_disk_barrier_failures(bctl->data.target)) {
> + btrfs_info(fs_info,
> + "Warning: metatdata has lower redundancy than data\n");
> + }
> +
> if (bctl->sys.flags & BTRFS_BALANCE_ARGS_CONVERT) {
> fs_info->num_tolerated_disk_barrier_failures = min(
> btrfs_calc_num_tolerated_disk_barrier_failures(fs_info),
>
next prev parent reply other threads:[~2015-10-05 2:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-03 15:50 [PATCH v2] Btrfs: Check metadata redundancy on balance sam tygier
2015-10-05 2:33 ` Anand Jain [this message]
2015-10-07 8:19 ` sam tygier
-- strict thread matches above, loose matches on Subject: below --
2015-11-03 9:28 sam tygier
2015-12-08 9:25 sam tygier
2016-01-05 14:41 ` David Sterba
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=5611E169.1060902@oracle.com \
--to=anand.jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=samtygier@yahoo.co.uk \
/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).