From: Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Jan Prusakowski <jprusakowski@google.com>,
Zorro Lang <zlang@kernel.org>,
fstests@vger.kernel.org
Cc: jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v2] generic/622: increase sleep time for lazytime expiration
Date: Wed, 14 Oct 2026 18:52:35 +0800 [thread overview]
Message-ID: <320a0790-c6fe-4da9-bb77-4490e88946ef@kernel.org> (raw)
In-Reply-To: <20261009085544.2450966-1-jprusakowski@google.com>
On 10/9/26 16:55, Jan Prusakowski wrote:
> In generic/622, expire_timestamps() tests whether lazytime timestamp
> updates are persisted after dirtytime expiration. It configures
> dirtytime_expire_seconds to 1 second and enables continuous writeback
> of dirty inodes, followed by sleeping for 2 seconds to allow the
> asynchronous VFS flusher thread to expire the I_DIRTY_TIME inode,
> invoke the filesystem's write_inode callback, and flush the dirty
> metadata before the test executes _scratch_shutdown -f.
>
> However, on filesystems or configurations with higher writeback
> overhead -- such as F2FS with transparent compression enabled, where
> compressed files cannot use inline data and writes use out-of-place
> updates (OPU) with higher latency in the compression and writeback
FYI, I encounter similar issue on non-compressed inode, so v2 w/o checking
compression makes sense to me.
> pipeline -- the 2-second sleep window can occasionally be insufficient.
> Because the inode is only eligible for expiration after 1 second, only
> about 1 second remains in the 2-second sleep window for the flusher
> thread to schedule, expire the inode, and mark the inode page dirty
> before restore_expiration_settings resets dirtytime_expire_seconds to
> 24 hours and shutdown occurs. If the flusher thread is delayed, the
> subsequent shutdown checkpoint ignores the unexpired I_DIRTY_TIME inode,
> causing the test to intermittently fail with:
>
> FAIL: lazytime mtime wasn't persisted by expiration
> ondisk_time (...) != expected_time (...)
>
> Increase the sleep duration in expire_timestamps() from 2 to 4 seconds
> to give sufficient margin for the flusher thread to reliably expire the
> lazytime inode and dirty the inode page before shutdown.
>
> Signed-off-by: Jan Prusakowski <jprusakowski@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Thanks,
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Chao Yu <chao@kernel.org>
To: Jan Prusakowski <jprusakowski@google.com>,
Zorro Lang <zlang@kernel.org>,
fstests@vger.kernel.org
Cc: chao@kernel.org, jaegeuk@kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH v2] generic/622: increase sleep time for lazytime expiration
Date: Wed, 14 Oct 2026 18:52:35 +0800 [thread overview]
Message-ID: <320a0790-c6fe-4da9-bb77-4490e88946ef@kernel.org> (raw)
In-Reply-To: <20261009085544.2450966-1-jprusakowski@google.com>
On 10/9/26 16:55, Jan Prusakowski wrote:
> In generic/622, expire_timestamps() tests whether lazytime timestamp
> updates are persisted after dirtytime expiration. It configures
> dirtytime_expire_seconds to 1 second and enables continuous writeback
> of dirty inodes, followed by sleeping for 2 seconds to allow the
> asynchronous VFS flusher thread to expire the I_DIRTY_TIME inode,
> invoke the filesystem's write_inode callback, and flush the dirty
> metadata before the test executes _scratch_shutdown -f.
>
> However, on filesystems or configurations with higher writeback
> overhead -- such as F2FS with transparent compression enabled, where
> compressed files cannot use inline data and writes use out-of-place
> updates (OPU) with higher latency in the compression and writeback
FYI, I encounter similar issue on non-compressed inode, so v2 w/o checking
compression makes sense to me.
> pipeline -- the 2-second sleep window can occasionally be insufficient.
> Because the inode is only eligible for expiration after 1 second, only
> about 1 second remains in the 2-second sleep window for the flusher
> thread to schedule, expire the inode, and mark the inode page dirty
> before restore_expiration_settings resets dirtytime_expire_seconds to
> 24 hours and shutdown occurs. If the flusher thread is delayed, the
> subsequent shutdown checkpoint ignores the unexpired I_DIRTY_TIME inode,
> causing the test to intermittently fail with:
>
> FAIL: lazytime mtime wasn't persisted by expiration
> ondisk_time (...) != expected_time (...)
>
> Increase the sleep duration in expire_timestamps() from 2 to 4 seconds
> to give sufficient margin for the flusher thread to reliably expire the
> lazytime inode and dirty the inode page before shutdown.
>
> Signed-off-by: Jan Prusakowski <jprusakowski@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Thanks,
next prev parent reply other threads:[~2026-10-14 10:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 8:55 [f2fs-dev] [PATCH v2] generic/622: increase sleep time for lazytime expiration Jan Prusakowski via Linux-f2fs-devel
2026-10-09 8:55 ` Jan Prusakowski
2026-10-12 12:33 ` [f2fs-dev] " Christoph Hellwig
2026-10-12 12:33 ` Christoph Hellwig
2026-10-14 10:52 ` Chao Yu via Linux-f2fs-devel [this message]
2026-10-14 10:52 ` Chao Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=320a0790-c6fe-4da9-bb77-4490e88946ef@kernel.org \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=chao@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=jaegeuk@kernel.org \
--cc=jprusakowski@google.com \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.