From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A33D331578E; Mon, 18 May 2026 05:12:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779081143; cv=none; b=E0meaC9DSmB26o+E19npiLsbsLLQTFgi63cpRnAxtwFm9Jj6QkRMR/3zvORi8fKR4CQrj+c/lZVHoFR5M0pussBW8b4WMEi/+iq1ik8HI/vT/MA9T6Xk0kj8mSINTJ44VTFaD+9o+oifOblKpUh82i/mmuEEmTmWvpBNJXwT30c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779081143; c=relaxed/simple; bh=3k4iwQV1oGU42ZOJIoH7bSeLPlTONhWevQ8jf4pH0NE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WUUy7UhM+1hlXcVrBGKaHF1scqjySgFELsdvGszUIoj5gfXNBW2SO+NrU2PaxIH5mNRk69euY2INeTiA7x7Mze/BpZjpWzEWNUZOGYuUXi6/a/qTthnt2gnujgupy405h0XOu87Kcn3LTIYCyOiy8WiRh68POH6znxPZPtIWbk8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de 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> Precedence: bulk X-Mailing-List: linux-raid@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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) 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.