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 3C989CD4F3C for ; Fri, 15 May 2026 04:37:23 +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=/R8ozgf+55DzMr8+wU9geLZu52m9aFdrT2CH63clcjM=; b=X+opZXliXn7QqAvpwUqDNJJP0M sL5hQ4Eegxf+1btLUH3EiKB1HGeXQo8VRk9Shrznvluddk2of3TMDVJt6liXS2v8hZVOTZj2z8yV7 0RVKFtv2OLuCwTNamuMPzrvhN5la6KnbZBpAqO/oozH6AIK3SI7xHQFpEIcU+5sl1Vgue+/ncjTQw qm31CDXovTbTnWaIvUE1/iH7An4NI6zTUW4KFBIjnYdUa0QNcc3cIjANzFkgsGVH2VmEGnDUS+yqt lvKtM5lFN8uwOqOspdmI5us95HeMu5aRAGRp/100oEeYtg6dX/LRE7yfkZaduX/NDxHKEleLYOfQ7 KjafW9dg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wNkIU-00000007Jps-0Qpn; Fri, 15 May 2026 04:37:14 +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 1wNkIQ-00000007Jp2-2tFS; Fri, 15 May 2026 04:37:11 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 1B35A6732A; Fri, 15 May 2026 06:37:06 +0200 (CEST) Date: Fri, 15 May 2026 06:37:05 +0200 From: Christoph Hellwig To: kreijack@inwind.it Cc: Christoph Hellwig , 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, "H. Peter Anvin" , 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: <20260515043705.GA3855@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a8d1ff4-f5a2-49e9-aa45-d25dbe4ded40@libero.it> 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-20260514_213710_865923_C51FF11C X-CRM114-Status: GOOD ( 13.62 ) 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 Thu, May 14, 2026 at 09:51:59PM +0200, Goffredo Baroncelli wrote: > I think that the David concern is : "what happens for an already > existing btrfs raid6 3 disks filesystem when the user upgrade the kernel ?" > (I am thinking when a new BG needs to be allocated)... Then it will cleanly fail to mount instead of constantly corrupting data and memory with every write, yes. Which clearly suggest that such file systems don't exist in the wild. But if btrfs wants to keep supporting this I'll just add a _unsafe version without the check in the core library.