From: "Richter, Rafael" <rafael.richter.extern@gin.de>
To: Jan Kara <jack@suse.cz>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: AW: ext4: slow unmount with large clean page cache; is fsfreeze→umount recommended?
Date: Thu, 18 Sep 2025 05:55:45 +0000 [thread overview]
Message-ID: <b76d3334a0b14a709ef3c3c197f5ddf5@gin.de> (raw)
In-Reply-To: <db7ikfrvqkz6ovmpsaahkwozdizeq34ev6nhnxaldwlhbklx7x@vxl5e6hu2c6e>
Hi!
> Yes. This is because with this kernel version XFS uses large folios (upto
> 2MB in size) while ext4 uses only 4k folios for the page cache. And
> evicting that many folios in ext4 takes time. Large folio support has been
> added to ext4 recently (6.16?) so with that you should see similar umount
> times again.
Thank you for this valuable information. I will give it a try.
Von: Jan Kara <jack@suse.cz>
Gesendet: Mittwoch, 17. September 2025 17:58
An: Richter, Rafael
Cc: linux-ext4@vger.kernel.org
Betreff: Re: ext4: slow unmount with large clean page cache; is fsfreeze→umount recommended?
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi!
On Fri 12-09-25 14:20:13, Richter, Rafael wrote:
> we consistently see slow unmounts (~6–8s) on ext4 after heavy buffered writes
> (e.g., dd ~30 GiB) that grow the page cache. Same test on XFS unmounts <1s on
> the same hardware, but we must stay on ext4.
>
> Env:
> - Kernel: 6.6.36 (Yocto-based)
> - Device: SSD via mdraid (/dev/md0p1)
> - Mount: ext4 on /mnt/disk (defaults)
>
> Repro:
> dd if=/dev/zero of=/mnt/disk/big.bin bs=1M count=30720 status=progress
> sync -f /mnt/disk
> time umount /mnt/disk # ext4: ~6–8s
Yes. This is because with this kernel version XFS uses large folios (upto
2MB in size) while ext4 uses only 4k folios for the page cache. And
evicting that many folios in ext4 takes time. Large folio support has been
added to ext4 recently (6.16?) so with that you should see similar umount
times again.
> Observations:
> - Dirty/Writeback are ~0 before unmount.
> - `fsfreeze -f /mnt/disk` immediately before `umount` makes unmount very fast.
> - `mount -o remount,ro` before `umount` does NOT improve unmount time.
Well, this is definitely not recommended. fsfreeze -f will acquire
superblock reference which means that the filesystem actually stays mounted
in the background after umount until you unfreeze it (for which you need to
mount it again ;)). That's a bit of a catch with fsfreeze.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2025-09-18 6:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-12 14:20 ext4: slow unmount with large clean page cache; is fsfreeze→umount recommended? Richter, Rafael
2025-09-17 15:58 ` Jan Kara
2025-09-18 5:55 ` Richter, Rafael [this message]
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=b76d3334a0b14a709ef3c3c197f5ddf5@gin.de \
--to=rafael.richter.extern@gin.de \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).