From patchwork Wed Mar 23 18:22:59 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Austin S. Hemmelgarn" X-Patchwork-Id: 8653031 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 4D815C0553 for ; Wed, 23 Mar 2016 18:23:27 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6574A203DB for ; Wed, 23 Mar 2016 18:23:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 72854203E3 for ; Wed, 23 Mar 2016 18:23:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756041AbcCWSXW (ORCPT ); Wed, 23 Mar 2016 14:23:22 -0400 Received: from mail-qk0-f171.google.com ([209.85.220.171]:34274 "EHLO mail-qk0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751430AbcCWSXV (ORCPT ); Wed, 23 Mar 2016 14:23:21 -0400 Received: by mail-qk0-f171.google.com with SMTP id p130so10355210qke.1 for ; Wed, 23 Mar 2016 11:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=ISALjDnN86GUqxR3kMHWQY5XeWx4P3uYVHWl0jYmk9k=; b=odw3yLZ2h6H5KsrdcgQesOHYuo8i0l2L1+TjB/eorJWM0JR9LlHO115a2WGb4pd5T5 H3jasZYhkuDPVKt8VuTFWDf/3Azj1LeUYRv5YKGTMX741koGWJ7wFJHEGLJJ7+JGr/IU goIxD56n5g+zHTjGoG6bEeAmmcqIcUxjrJer+TZL0pdwtlaQAFyOJxsweYlbHjBCxCAp xwWcfITqOS3dEQavLlGyTwc5AJEubanBg2C/qif05P37yXTmCF/a8FGbYQcLbei8RoH2 gM8qYggzzl/brN5y0hnKOURjwudXGDjIjOsuKyo9fiZGzYZpYrtfPDZBoeX/bV8bAasI OU3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=ISALjDnN86GUqxR3kMHWQY5XeWx4P3uYVHWl0jYmk9k=; b=TLSwcEJZrDZlNxK5gV/pRRLIraRepMIdXyi6L25VxsXXIGNEATIudeO2Z+zcRWkF53 LfIESHdGowKKZVEv1oyvWke5e2ag42hbVl/TTRCD07mRHNS9cSdYCOOcH2vmxVo0fOAB 7tlI4wydGtbabxkhJKbSDzWiNRs2zkS1fYzZXz4DwoBzib2Cf1ZFa5OdPU5Sl3QmF9Do QfzA8lOB8v/92l74/2wnl74VwAFjS8bDcyD5AnSZ6DAUsgH2aFmWn3nocV15A75Cn1/D 7kNx/kQ4I/6c0Ne3HMWqVFi+6WZfnZAZZAwqV6cgFKvCPAgSRGI0OqxVhoYA7+kxs8Fy HHKg== X-Gm-Message-State: AD7BkJLH2e2gi8tBkkGCY2m4dRnBUWfLJY/9mcp4MJUWdF/T2SHte3WuWJLmLMgPZypo0A== X-Received: by 10.55.81.2 with SMTP id f2mr5538992qkb.87.1458757400359; Wed, 23 Mar 2016 11:23:20 -0700 (PDT) Received: from wild-karde.localdomain (rrcs-70-62-41-24.central.biz.rr.com. [70.62.41.24]) by smtp.googlemail.com with ESMTPSA id v74sm1567587qkl.36.2016.03.23.11.23.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Mar 2016 11:23:19 -0700 (PDT) Received: by wild-karde.localdomain (Postfix, from userid 1000) id 8C6331A56EA8; Wed, 23 Mar 2016 14:23:17 -0400 (EDT) From: "Austin S. Hemmelgarn" To: linux-btrfs@vger.kernel.org, dsterba@suse.com, clm@fb.com, jbacik@fb.com Cc: "Austin S. Hemmelgarn" Subject: [RFC][PATCH] btrfs: allow balancing to dup with multi-device Date: Wed, 23 Mar 2016 14:22:59 -0400 Message-Id: <1458757379-36299-1-git-send-email-ahferroin7@gmail.com> X-Mailer: git-send-email 2.7.4 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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;