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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78A86C433FE for ; Mon, 9 May 2022 14:32:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237261AbiEIOgn (ORCPT ); Mon, 9 May 2022 10:36:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237253AbiEIOgh (ORCPT ); Mon, 9 May 2022 10:36:37 -0400 Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F569344EA; Mon, 9 May 2022 07:32:43 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id B434332002E8; Mon, 9 May 2022 10:32:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 09 May 2022 10:32:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1652106758; x=1652193158; bh=q2fT6PeM+A UuJffXe5pQrhxNHgfVI2C0XP0Aur0lGRQ=; b=A4iBPsoEz6TeExjL15OtRvqOBD Rcgj3CEIbFxNDBWpEOvWhgqSxyHYQgHzP6L2rHOv76GyG2I8roO2CBtUMXeUs9QD 9VdNunZ3MY4PUGwckFplrl6SaD7x1jthvmNhxwLdwubzx4mOgdtLu9Z/zpGIRuBK j1KPJ7/XdMqca2UVchc69aKrhnPXpz12NcwZ+T24LZUov1Bb/Phmy/kh6p9DzewY tUe/vFcTfB2Np5VcQNEXnLeBl9LyKQGDcETW7lxcOVZiAuAAszWFcl6rRNknCpPg WZ5ihOadmgWalMt133ueUqziTTCpokipTDuBUMKmg6wPOeR6VJ3oWB+alKkA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1652106758; x= 1652193158; bh=q2fT6PeM+AUuJffXe5pQrhxNHgfVI2C0XP0Aur0lGRQ=; b=y Wjkna7tbZljgf02Qd2QXFkFZGxDoYaNx5upaQcv6P7XX8BwjG2UAk1Zgy9Ow6Wd+ KpBBa1qP4bBchGr5EIWsorFwDSDweMKcktE44Q/HTrSqXzT3BoDdLB6e6GQzVuou SygHBe67fXPrAa0G8VcNbV51JdAxwipgyX2LVWI9CPlFx09rUQtbkCmqz84BVGkB 5H388WSa9pvcarZeT8YQ1n5jEIwQX2qGYyTTyhDHkh4oPCGvHVNaOtAAV+nApeBY Qa7YaeHxaC2gNhy156KPUp+53bcGXCrvLAOFyL9fBw7D4Huie/RRqw4QALjfOQek wpIPFsgrf+qVS/vDmWL6w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeelgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefirhgvghcu mffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtffrrghtthgvrhhnpeegheeuhe fgtdeluddtleekfeegjeetgeeikeehfeduieffvddufeefleevtddtvdenucffohhmrghi nhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 May 2022 10:32:37 -0400 (EDT) Date: Mon, 9 May 2022 16:32:35 +0200 From: Greg KH To: Qu Wenruo Cc: stable@vger.kernel.org, linux-btrfs@vger.kernel.org, Matt Corallo , Josef Bacik , David Sterba Subject: Re: [PATCH stable-5.15.y] btrfs: force v2 space cache usage for subpage mount Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Mon, May 09, 2022 at 05:28:56PM +0800, Qu Wenruo wrote: > commit 9f73f1aef98b2fa7252c0a89be64840271ce8ea0 upstream. > > [BUG] > For a 4K sector sized btrfs with v1 cache enabled and only mounted on > systems with 4K page size, if it's mounted on subpage (64K page size) > systems, it can cause the following warning on v1 space cache: > > BTRFS error (device dm-1): csum mismatch on free space cache > BTRFS warning (device dm-1): failed to load free space cache for block group 84082688, rebuilding it now > > Although not a big deal, as kernel can rebuild it without problem, such > warning will bother end users, especially if they want to switch the > same btrfs seamlessly between different page sized systems. > > [CAUSE] > V1 free space cache is still using fixed PAGE_SIZE for various bitmap, > like BITS_PER_BITMAP. > > Such hard-coded PAGE_SIZE usage will cause various mismatch, from v1 > cache size to checksum. > > Thus kernel will always reject v1 cache with a different PAGE_SIZE with > csum mismatch. > > [FIX] > Although we should fix v1 cache, it's already going to be marked > deprecated soon. > > And we have v2 cache based on metadata (which is already fully subpage > compatible), and it has almost everything superior than v1 cache. > > So just force subpage mount to use v2 cache on mount. > > Reported-by: Matt Corallo > CC: stable@vger.kernel.org # 5.15+ > Link: https://lore.kernel.org/linux-btrfs/61aa27d1-30fc-c1a9-f0f4-9df544395ec3@bluematt.me/ > Reviewed-by: Josef Bacik > Signed-off-by: Qu Wenruo > Signed-off-by: David Sterba > --- > fs/btrfs/disk-io.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) Now queued up, thanks. greg k-h