Re: [RFC][PATCH] btrfs: allow balancing to dup with multi-device

2016-03-24 Thread David Sterba
On Wed, Mar 23, 2016 at 02:22:59PM -0400, Austin S. Hemmelgarn wrote:
> Currently, we don't allow the user to try and rebalance to a dup profile
> on a multi-device filesystem.  In most cases, this is a perfectly sensible
> restriction as raid1 uses the same amount of space and provides better
> protection.
> 
> However, when reshaping a multi-device filesystem down to a single device
> filesystem, this requires the user to convert metadata and system chunks
> to single profile before deleting devices, and then convert again to dup,
> which leaves a period of time where metadata integrity is reduced.
> 
> This patch removes the single-device-only restriction from converting to
> dup profile to remove this potential data integrity reduction.
> 
> Signed-off-by: Austin S. Hemmelgarn 

Ack. I did exactly same patch a week ago, the changelogs sound
equivalent to me, so I'll drop my patch and take yours.

http://repo.or.cz/linux-2.6/btrfs-unstable.git/commitdiff/d9929bfeec0abf24ae7fdbc5855914fe7f3886c9?hp=b562e44f507e863c6792946e4e1b1449fbbac85d

I did the btrfs-progs side as well, that prints a warning but otherwise
lets the user create dup on multi-dev filesystem.

http://repo.or.cz/btrfs-progs-unstable/devel.git/commitdiff/22c67c3105c887f541d7353d79d9e11b68e70998
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RFC][PATCH] btrfs: allow balancing to dup with multi-device

2016-03-23 Thread Austin S. Hemmelgarn
Currently, we don't allow the user to try and rebalance to a dup profile
on a multi-device filesystem.  In most cases, this is a perfectly sensible
restriction as raid1 uses the same amount of space and provides better
protection.

However, when reshaping a multi-device filesystem down to a single device
filesystem, this requires the user to convert metadata and system chunks
to single profile before deleting devices, and then convert again to dup,
which leaves a period of time where metadata integrity is reduced.

This patch removes the single-device-only restriction from converting to
dup profile to remove this potential data integrity reduction.

Signed-off-by: Austin S. Hemmelgarn 
---
A few years back I had sent a patch to do this to the ML, got asked to
rebase it, didn't have the time to do so then, and forgot about it as
the use case this caters to is not one that I have to deal with every day.

Recent discussion on the ML of using DUP for data on single devices,
combined with me having to preform a similar conversion on a filesystem
reminded me of this limitation, so I decided to redo the patch in a minimal
form and see what everyone's opinion of this was before going any further.
I intend to add something to warn when someone converts to dup on a
multi-device FS, but wanted to get some idea of whether the warning
should be from the kernel or userspace, and whether or not we should
require force for this or not (I'm personally indifferent on both counts).

 fs/btrfs/volumes.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 3f9f33c..09ca950 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3682,10 +3682,8 @@ int btrfs_balance(struct btrfs_balance_control *bctl,
num_devices--;
}
btrfs_dev_replace_unlock(&fs_info->dev_replace, 0);
-   allowed = BTRFS_AVAIL_ALLOC_BIT_SINGLE;
-   if (num_devices == 1)
-   allowed |= BTRFS_BLOCK_GROUP_DUP;
-   else if (num_devices > 1)
+   allowed = BTRFS_AVAIL_ALLOC_BIT_SINGLE | BTRFS_BLOCK_GROUP_DUP;
+   if (num_devices > 1)
allowed |= (BTRFS_BLOCK_GROUP_RAID0 | BTRFS_BLOCK_GROUP_RAID1);
if (num_devices > 2)
allowed |= BTRFS_BLOCK_GROUP_RAID5;
--
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html