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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (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 60102C43458 for ; Mon, 29 Jun 2026 16:37:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DeUddijGdANcCNj+TQK93BGaXNz5Bz0yOLhm/Hl4VYM=; b=S/4QANQxUBrnDR1LkY04aJzRd+ 8ddzhd2SJ303vtSJ53bnjm/uxzCM8Ap2SH5Pkz8n/AoqvFBzOKSgEB0lVQfR6cGV75AonIeoCmMo6 HPvnjppt+onHnr3X8MFFfA0NysYDa4nLu03qdFmpuJtEEv5wBoGMs1lRQSkud+beZj00=; Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1weEzV-0004YD-8m; Mon, 29 Jun 2026 16:37:49 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1weEzU-0004Y7-7S for linux-f2fs-devel@lists.sourceforge.net; Mon, 29 Jun 2026 16:37:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=7JHewKYa5/FTTPDRStSCJXtjBGuHptHfKbTCR8wXYao=; b=fGBVvIttiGMs4tdX1iyaxCE8qg 0ZjnStvvepEZ0ANcxywHGIWWJDfxFZPvV0OAMBVMMgnQu1l/WIGK/2piCWUVPydm0SQVDNurfb0Bh zhnoqNh/2EmC08ECOCMebP3467u/qbNZRxIfN8s19+Qm4vVdOXVWJ3mb8hVhaq2+Zbz0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7JHewKYa5/FTTPDRStSCJXtjBGuHptHfKbTCR8wXYao=; b=FPjGkGM36xVZXt4GcIybEJQRuZ HegJOCCMfgp/JDjbGUFMkpy8yb3qA9Z5Oo+S70DkS4t45v9DWWUKGZXuMB9jbZxKV8mjaZ2R/Dgi8 o447YJVgHREDWzti5InTWiASw8NMTiv29s4SKR0ugmz7a/e11uuT9tkN3rDYYh7AdZtA=; Received: from sea.source.kernel.org ([172.234.252.31]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1weEzR-0006Ji-5l for linux-f2fs-devel@lists.sourceforge.net; Mon, 29 Jun 2026 16:37:48 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 4458443887; Mon, 29 Jun 2026 16:37:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDAED1F000E9; Mon, 29 Jun 2026 16:37:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782751055; bh=7JHewKYa5/FTTPDRStSCJXtjBGuHptHfKbTCR8wXYao=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=a69pGlB4jKPrTsc+I/siJAuw8v/xiP50xITuIxUZv7uXRzugRpCea1B0Ft9FLa01J 3aSWZqW7Ix0lmLmF3NF9XVKH/1McKzT2BoQQAQiVeyMUYdKl0rMIaY9LVunZjUPSxZ vIO3uTlKlAPO84EPoNMo0wWq4aRtDwV4G4evF3ij79hy3HQSLbwMghZRdKc0LRNDcX 56WWWmKBqEMjtzuSrAQnAv+2IIrm5JiUtd+fNzROy3jU6ie1bTwl2kvgfAmxFK2V6A HJiVmvcdfYS6T/oH/9gABsW75rT/07LcWgNF2fIdmju9ZtavTELMm7wgcfr7rQ1Lds PDY7gq6Ns8hYQ== Date: Tue, 30 Jun 2026 00:37:29 +0800 To: Jan Prusakowski Message-ID: Mail-Followup-To: Jan Prusakowski , Christoph Hellwig , fstests@vger.kernel.org, jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net References: <20260622070438.1542638-1-jprusakowski@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Headers-End: 1weEzR-0006Ji-5l Subject: Re: [f2fs-dev] [PATCH] generic/064: allow 50 extents on F2FS after fcollapse X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Zorro Lang via Linux-f2fs-devel Reply-To: Zorro Lang Cc: Christoph Hellwig , jaegeuk@kernel.org, fstests@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Wed, Jun 24, 2026 at 12:46:01AM -0700, Christoph Hellwig wrote: > On Mon, Jun 22, 2026 at 07:04:38AM +0000, Jan Prusakowski wrote: > > On F2FS, generic/064 fails with "extents mismatched before = 1 after = > > 50" following multiple fcollapse (collapse range) operations. > > > > To ensure crash consistency and checkpoint integrity, F2FS forbids > > in-place SSR (Summary Standalone Replacement) overwrites on valid > > checkpointed blocks. When collapse range shifts blocks, F2FS allocates > > new data pages in LFS mode (out-of-place log writes). As a result, > > sequential collapse range calls rewrite shifted blocks at new log > > locations, intentionally leaving the file with 50 extents. > > This sounds odd. The test allocates a contigous range and then just does > insert/collapse on it, which should not lead to any new data block > allocations. Given that the test works fine on zoned XFS and btrfs > with strict out of place write policies we know it does not require > overwriting blocks to work as well. > > So I think something is fishy in f2fs if needs to allocate data blocks > here. I have the same question with Christoph. Shouldn't fcollapse in F2FS just remap the metadata instead of allocating new data blocks? > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 6886140315B for ; Mon, 29 Jun 2026 16:37:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782751056; cv=none; b=RNpYOkBijqlmIX+Lp9Af0GUCmyIqZ8dwBOLC0byxnIJE3TmkVwfdPLHCtF6Qk5hZeFycKgbHWXB132CEK0A3gWSbeB5kYpCWgDetAYFDeCcQc46Az1ajwUO2AzF2MmqIrKnlIkTTx3BAWpv4XtxLYSU4vOS0h4rwpWoJuz9wA4k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782751056; c=relaxed/simple; bh=Ly2eM5usbijVbR3s3cQl200vfsIvIuCXQcLe7fOGQnM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SmPmySAFtvpTlsIJgiJ4po8yKZMr5nGNzGxE3leDJ26CHkRlZ5o9QUjtdZHWvm7KfVnLU4oWYitzmSfJlLz8wo4B1pWnqWhuOV9zvIgsB4zVasvknmDgHDAi2Wveor5BH1cJoPaCgvsM5iEtqFPGAXQCojXwK4TdFuD05FwEQ08= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a69pGlB4; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a69pGlB4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDAED1F000E9; Mon, 29 Jun 2026 16:37:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782751055; bh=7JHewKYa5/FTTPDRStSCJXtjBGuHptHfKbTCR8wXYao=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=a69pGlB4jKPrTsc+I/siJAuw8v/xiP50xITuIxUZv7uXRzugRpCea1B0Ft9FLa01J 3aSWZqW7Ix0lmLmF3NF9XVKH/1McKzT2BoQQAQiVeyMUYdKl0rMIaY9LVunZjUPSxZ vIO3uTlKlAPO84EPoNMo0wWq4aRtDwV4G4evF3ij79hy3HQSLbwMghZRdKc0LRNDcX 56WWWmKBqEMjtzuSrAQnAv+2IIrm5JiUtd+fNzROy3jU6ie1bTwl2kvgfAmxFK2V6A HJiVmvcdfYS6T/oH/9gABsW75rT/07LcWgNF2fIdmju9ZtavTELMm7wgcfr7rQ1Lds PDY7gq6Ns8hYQ== Date: Tue, 30 Jun 2026 00:37:29 +0800 From: Zorro Lang To: Jan Prusakowski Cc: Christoph Hellwig , fstests@vger.kernel.org, jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [PATCH] generic/064: allow 50 extents on F2FS after fcollapse Message-ID: Mail-Followup-To: Jan Prusakowski , Christoph Hellwig , fstests@vger.kernel.org, jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net References: <20260622070438.1542638-1-jprusakowski@google.com> Precedence: bulk X-Mailing-List: fstests@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: On Wed, Jun 24, 2026 at 12:46:01AM -0700, Christoph Hellwig wrote: > On Mon, Jun 22, 2026 at 07:04:38AM +0000, Jan Prusakowski wrote: > > On F2FS, generic/064 fails with "extents mismatched before = 1 after = > > 50" following multiple fcollapse (collapse range) operations. > > > > To ensure crash consistency and checkpoint integrity, F2FS forbids > > in-place SSR (Summary Standalone Replacement) overwrites on valid > > checkpointed blocks. When collapse range shifts blocks, F2FS allocates > > new data pages in LFS mode (out-of-place log writes). As a result, > > sequential collapse range calls rewrite shifted blocks at new log > > locations, intentionally leaving the file with 50 extents. > > This sounds odd. The test allocates a contigous range and then just does > insert/collapse on it, which should not lead to any new data block > allocations. Given that the test works fine on zoned XFS and btrfs > with strict out of place write policies we know it does not require > overwriting blocks to work as well. > > So I think something is fishy in f2fs if needs to allocate data blocks > here. I have the same question with Christoph. Shouldn't fcollapse in F2FS just remap the metadata instead of allocating new data blocks? >