From patchwork Thu Dec 1 20:01:17 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: 9456767 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5E27B60235 for ; Thu, 1 Dec 2016 20:01:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4DDD21FF21 for ; Thu, 1 Dec 2016 20:01:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 426CF284A0; Thu, 1 Dec 2016 20:01:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A589E1FF21 for ; Thu, 1 Dec 2016 20:01:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755399AbcLAUBc (ORCPT ); Thu, 1 Dec 2016 15:01:32 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:33031 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753431AbcLAUBb (ORCPT ); Thu, 1 Dec 2016 15:01:31 -0500 Received: by mail-io0-f193.google.com with SMTP id j92so3186529ioi.0 for ; Thu, 01 Dec 2016 12:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=BhV6NtjDOhPro4kjfGcMNMswMbeVMO4zhQ7SA4O3B/4=; b=PsT+HB/QkYx9vr0sxu/Qd3f7mM2Jpco9Y40vOYVCSfgL0+pllrNR4CYPTg5x4JuTEk r+cmnqrp5OI9H5M97KscWOVNzjWOKvBCCnar1oDOFU06eu68U4Z369n5CODXn0iYInAh 4rC4y2V6Mtj22UaCO6auv/xFrpy4VJMV7s0s6eBY2GGIGDeSyfm1Imm76neYw1cZkWTo r9wDWA9e7Ib9Q02Tx+xrLVlVX+S/2DVYUp2GCxaTOQo2dKr3wsaR6YY8s1/v4jgGJ6GP 89DLX3qX2BxQyfpUq7y/AF4/MXt8Z7ZDd8aMK/oZK5ftGojgl47JYkqTppYbRFnr5Pj2 64Vw== 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=BhV6NtjDOhPro4kjfGcMNMswMbeVMO4zhQ7SA4O3B/4=; b=PkOqZ58qfMCHzfvRNIrNrKI1iuWaUT2BCzLcvl32/PzaTJPpIuI0yeL2ByYKBHpe2e Q0pZcx/NQlnYRWYB3BAZysK4lOJuLK5ffdk++yGq3mzSAkssa61/kujK3I8VkEm8Wvy/ fUrVpp6TMXnNiXx7zlXrXKmZYl785gjfVlUvFooNWzyAxrH3OZH2/dB3OzONj0P8yjdo 1rOSI4KkUrj6VCB5DfbLP2r1O7CWKq5B0qY7ZitcbkpCFKJ175K1N+U3fe87sLJnplUK qvIbndMcsi3kuRr6nqqTmPvceSl35Gh1DUAjAvJqEjC0ULbhYWtH2lqNh5xMKiuGGLAF Yk4w== X-Gm-Message-State: AKaTC01ZdlOfriTL/JlnVusqc1t79wPi9KoSYpcmGm7//6LhMtAZsclOifmtTYyqCQT80A== X-Received: by 10.107.20.210 with SMTP id 201mr35389976iou.84.1480622490025; Thu, 01 Dec 2016 12:01:30 -0800 (PST) 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 f4sm777542ioa.18.2016.12.01.12.01.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 12:01:29 -0800 (PST) Received: by wild-karde.localdomain (Postfix, from userid 1000) id 69E5B1E167B1; Thu, 1 Dec 2016 15:01:27 -0500 (EST) From: "Austin S. Hemmelgarn" To: dsterba@suse.cz, linux-btrfs@vger.kernel.org Cc: "Austin S. Hemmelgarn" Subject: [PATCH] btrfs-progs: doc: Update docs about RAID profiles Date: Thu, 1 Dec 2016 15:01:17 -0500 Message-Id: <20161201200117.6743-1-ahferroin7@gmail.com> X-Mailer: git-send-email 2.11.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This adds some more info about chunk profiles in the mkfs manpage, specifically providing better info about raid1 and raid10 profiles and the fact that they can't survive more than one device failing. This should hopefully make it less likely that people hit unexpected behavior when using these profiles. Signed-off-by: Austin S. Hemmelgarn --- This should work to cover most of the issues brought up on the mailing list recently regarding this particular aspect of documentation. Documentation/mkfs.btrfs.asciidoc | 44 ++++++++++++++++++++++++++++++++------- 1 file changed, 36 insertions(+), 8 deletions(-) diff --git a/Documentation/mkfs.btrfs.asciidoc b/Documentation/mkfs.btrfs.asciidoc index 9b1d45a..a5a8dc1 100644 --- a/Documentation/mkfs.btrfs.asciidoc +++ b/Documentation/mkfs.btrfs.asciidoc @@ -247,10 +247,10 @@ There are the following block group types available: | single | 1 | | | 1/any | DUP | 2 / 1 device | | | 1/any ^(see note 1)^ | RAID0 | | | 1 to N | 2/any -| RAID1 | 2 | | | 2/any -| RAID10 | 2 | | 1 to N | 4/any -| RAID5 | 1 | 1 | 2 to N - 1 | 2/any ^(see note 2)^ -| RAID6 | 1 | 2 | 3 to N - 2 | 3/any ^(see note 3)^ +| RAID1 | 2 | | | 2/any ^(see note 2)^ +| RAID10 | 2 | | 1 to N | 4/any ^(see note 2)^ +| RAID5 | 1 | 1 | 2 to N - 1 | 2/any ^(see note 3)^ +| RAID6 | 1 | 2 | 3 to N - 2 | 3/any ^(see note 4)^ |============================================================= WARNING: It's not recommended to build btrfs with RAID0/1/10/5/6 prfiles on @@ -261,13 +261,17 @@ improved. another one is added. Since version 4.5.1, *mkfs.btrfs* will let you create DUP on multiple devices. -'Note 2:' It's not recommended to use 2 devices with RAID5. In that case, +'Note 2:' BTRFS implementattions of RAID1 and RAID10 can only sustain +a *single* device failure before the filesystem is irreperably damaged, +no matter how many actual devices are in the aray. See 'KNOWN ISSUES' +below for more on this. + +'Note 3:' It's not recommended to use 2 devices with RAID5. In that case, parity stripe will contain the same data as the data stripe, making RAID5 -degraded to RAID1 with more overhead. +equivalent to RAID1 with more overhead. -'Note 3:' It's also not recommended to use 3 devices with RAID6, unless you +'Note 4:' It's also not recommended to use 3 devices with RAID6, unless you want to get effectively 3 copies in a RAID1-like manner (but not exactly that). -N-copies RAID1 is not implemented. DUP PROFILES ON A SINGLE DEVICE ------------------------------- @@ -345,6 +349,30 @@ The ENOSPC occurs during the creation of the UUID tree. This is caused by large metadata blocks and space reservation strategy that allocates more than can fit into the filesystem. +***MULTI-DEVICE BTRFS FILESYSTEMS AND PROFILE NAMING*** + +BTRFS supports multiple devices being used in one filesystem. +The terminology used for the different chunk profiles is somewhat +misleading because it just copies the closest term from traditional +storage amnagement technologies. In particular, RAID1 and RAID10 do +not function the same as an LVM or MD RAID1 or RAID10 volume. + +In BTRFS, RAID1 currently means exactly 2 copies are stored on separate +devices in the array. Support for higher levels of replication is +planned, but currently has no known ETA for inclusion. This means +that a BTRFS RAID1 filesystem actually functions more like an MD RAID10 +volume (2 copies of a block, rotating which disks are used), is only +guraanteed to survive a single device failure. + +The situation with RAID10 is a bit different. It actually does function +like most typical RAID10 implementations (2 copies striped across an +arbitrary number of disks). The big difference here is that in a +traditional RAID10 configuration, the mapping of mirrors to devices is +static (ie, part 1 of copy 1 of a block is always on device 1, part 2 +oc copy 1 on device 2, etc), while on BTRFS this mapping is pseudo-random. +The net result of this is that while it is theoretically possible for +a BTRFS RAID10 filesystem to survive multiple disk failures in certain +combinations, in practice it never happens. AVAILABILITY ------------