From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2E418CD343F for ; Mon, 18 May 2026 05:12:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wfA3V4UYeGAKyKwCJXkOu4cqGfFxlHwPxWPkn2wNacw=; b=yiNyUCitxKagnuV1aPbWogfwcO g+KrGKXzFGZYWFdWoQcCHfhgyi0Hude3Q5NYUvjYxcSBx5WlMbX6k0Mo/Zbi9Z4yfXyIospTVyasY 2RwBQLb9TU/4z8fMbgzAB2Stw9knsy+sEMxuFK2d7H9XJj6U3fkSA1cH+A8gmLjtazyI+wILTlwJ3 AWNUSZvnlGwSQcS0T02EqlxxPDAqEa3WR+MROvq8wTAExYmOwrOcof9fgiITvOuuQrBbxtO9ubD/o w0kB6SjgL7EnHQiLeBjq9ku8PTciG/ICB0RQqzUoqRs2WwUBonIZSVqAD3gul1j3vkCk5rSIgNLev QQStV/zQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wOqH8-0000000EEKc-0P8D; Mon, 18 May 2026 05:12:22 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wOqH4-0000000EEJQ-2xNw; Mon, 18 May 2026 05:12:20 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id A440768B05; Mon, 18 May 2026 07:12:07 +0200 (CEST) Date: Mon, 18 May 2026 07:12:07 +0200 From: Christoph Hellwig To: "H. Peter Anvin" Cc: Christoph Hellwig , kreijack@inwind.it, David Sterba , Andrew Morton , Catalin Marinas , Will Deacon , Ard Biesheuvel , Huacai Chen , WANG Xuerui , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Herbert Xu , Dan Williams , Chris Mason , David Sterba , Arnd Bergmann , Song Liu , Yu Kuai , Li Nan , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-arch@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6 Message-ID: <20260518051207.GB9374@lst.de> References: <20260512052230.2947683-1-hch@lst.de> <20260512052230.2947683-2-hch@lst.de> <20260512114231.GG2558453@suse.cz> <20260513054742.GA1018@lst.de> <0a8d1ff4-f5a2-49e9-aa45-d25dbe4ded40@libero.it> <20260515043705.GA3855@lst.de> <34C16854-1065-4542-8836-DDED58EC1844@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34C16854-1065-4542-8836-DDED58EC1844@zytor.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260517_221218_895492_3DC5D2E9 X-CRM114-Status: GOOD ( 15.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, May 15, 2026 at 12:59:34PM -0700, H. Peter Anvin wrote: > I don't think this is a good idea. Error out; it is the btrfs maintainers' job to ensure user data isn't lost. > > The RAID-6 code has *never* supported only 3 units, and if it ever worked for *any* of the implementations it was purely by accident. Speaking as the original author I should know; this was deliberate as in some cases the degenerate case (3) would have required extra trays in the code to no user benefit. > > I would not be surprised if the kernel crashed or corrupted the page cache in that case. It does, that's why I wanted to exclude it. Anyway, for the about to be resent version I'll drop this btrfs patch over the stated objection and will otherwise not change anything. This means the (IMHO hypothetical) users of this configuration will get a WARN_ON_ONCE triggered, but otherwise keep working (or rather not working) as before.