Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB59AC433F5 for ; Thu, 9 Sep 2021 13:46:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A8FC661371 for ; Thu, 9 Sep 2021 13:46:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354379AbhIINrJ (ORCPT ); Thu, 9 Sep 2021 09:47:09 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:46271 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376536AbhIINkg (ORCPT ); Thu, 9 Sep 2021 09:40:36 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id A738432003D3; Thu, 9 Sep 2021 09:39:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 09 Sep 2021 09:39:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=41Udo73aOdvDOjD4k8iPY3mPwcC C3oWIAmkjSaZ5Igc=; b=DVDclqBG3LQvs3D8DYSXqXyq72ZNjP93z+9Be/kFRre +gDU7WoCiN/ewNJDvwpI+EntP06bCo+enyKwsbivbpP5/jrVoQh8lE+fzvxJxrnV Lx5EqoPxSl4ZwOglhgGJTCbIZtyg3bwSSHG3xQYCDWUZjVo7VUpDNDIhDFiJXKGa 6ip1egldwFc76CmQnu2wf+UcPQ6AeOFoebCD7mn4hfYSRDEwON2mjV55s+xBQaAG GYdoGOGaE8UUyUZUZQ5AsRj0ZVoM4x3FGwLIx1UqcNihyHq3N5Sn97PqHh7CAFMm BMfqk77IzobeYG+9le5VMVgGSutztktC+AYwOJZFNfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=41Udo7 3aOdvDOjD4k8iPY3mPwcCC3oWIAmkjSaZ5Igc=; b=j0mip+y4fn7Xr3vJPpA8Hq qbq0AvCKJ+c2MrOfvJpL2WUe/Hp508+uyP6tRCfyWKt4OK2TuM+rGBrowUPQrnGy a8b++H92+un4byKd3t1JoDsudiuHwtyH33xPb1nJHQpzW4PmsfZTKu+1XEuaBu7t jhklAdzzDcVZ0kVYEd/AygaMWC9nRe4JPrMy+uujgZNAVDpxXp0u/V4ALqPziEzn aEOIer7ZxCJQDH+vGRwwP7DfdsTpmZ6205TNJ1FvMKbHir2rkIUcSGTBYly5QLQ7 z5iTA57xHRYAbwz0IVZKmXTBcJUlYD9FNkzNxOWFepjWWojDwEVcVgjfv3lyo+CA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudefledgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefirhgvghcu mffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtffrrghtthgvrhhnpeeuleeltd ehkeeltefhleduuddvhfffuedvffduveegheekgeeiffevheegfeetgfenucffohhmrghi nhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Sep 2021 09:39:18 -0400 (EDT) Date: Thu, 9 Sep 2021 15:39:15 +0200 From: Greg KH To: David Sterba Cc: stable@vger.kernel.org Subject: Re: [PATCH stable 5.4, 4.19, 4.14] Revert "btrfs: compression: don't try to compress if we don't have enough pages" Message-ID: References: <20210909124750.29238-1-dsterba@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210909124750.29238-1-dsterba@suse.com> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Sep 09, 2021 at 02:47:50PM +0200, David Sterba wrote: > From: Qu Wenruo > > commit 4e9655763b82a91e4c341835bb504a2b1590f984 upstream. > > This reverts commit f2165627319ffd33a6217275e5690b1ab5c45763. > > [BUG] > It's no longer possible to create compressed inline extent after commit > f2165627319f ("btrfs: compression: don't try to compress if we don't > have enough pages"). > > [CAUSE] > For compression code, there are several possible reasons we have a range > that needs to be compressed while it's no more than one page. > > - Compressed inline write > The data is always smaller than one sector and the test lacks the > condition to properly recognize a non-inline extent. > > - Compressed subpage write > For the incoming subpage compressed write support, we require page > alignment of the delalloc range. > And for 64K page size, we can compress just one page into smaller > sectors. > > For those reasons, the requirement for the data to be more than one page > is not correct, and is already causing regression for compressed inline > data writeback. The idea of skipping one page to avoid wasting CPU time > could be revisited in the future. > > [FIX] > Fix it by reverting the offending commit. > > Reported-by: Zygo Blaxell > Link: https://lore.kernel.org/linux-btrfs/afa2742.c084f5d6.17b6b08dffc@tnonline.net > Fixes: f2165627319f ("btrfs: compression: don't try to compress if we don't have enough pages") > CC: stable@vger.kernel.org # 4.4+ > Signed-off-by: Qu Wenruo > Reviewed-by: David Sterba > Signed-off-by: David Sterba > --- > fs/btrfs/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > index 29552d4f6845..33b8fedab6c6 100644 > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -543,7 +543,7 @@ static noinline int compress_file_range(struct async_chunk *async_chunk) > * inode has not been flagged as nocompress. This flag can > * change at any time if we discover bad compression ratios. > */ > - if (nr_pages > 1 && inode_need_compress(inode, start, end)) { > + if (inode_need_compress(inode, start, end)) { > WARN_ON(pages); > pages = kcalloc(nr_pages, sizeof(struct page *), GFP_NOFS); > if (!pages) { > -- > 2.33.0 > All now queued up, thanks. greg k-h