linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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),
>

  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).