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 9E141CD4F3C for ; Fri, 15 May 2026 04:42:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WfM6INZ/4/qVLGjvFNXXYS0PzYckE3uX7j1YRust6IU=; b=YkXNmyjdRhP/NF yixCoNigkfxkzHWLdYfgPgcHuRtqVipfsLjYhJemUiMZSK3lFn3yaOhgpUUT2eZCBAQryOUoj1Krf 2p5qNXEjx5rC8joLXf5twjSUHlyo5KCFkzXb4kNlgmvH4ZsQjOvpJasoSlchvom1qAw0crN98DOsm TtzGTfNVM8f3NF/uv0DC0BSnLDEBu+ROFuxaJefmhuVVW4aUjEDMfy9dfp1fnsPTKxK1q9irVbWlV oUp2Qb8AsY9sWLj/XrWIT0/vBy8vL9pL3j7A8jHG85ZdcuY8f+Rcm5LTq1IM80/CENU+yeNPbByq4 /vIjbhvEsjR8KlKIpMsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wNkIU-00000007Jpw-1Ezm; 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-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-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=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. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv