linux-ext4 - Re: ext4: slow unmount with large clean page cache; is fsfreeze→umount recommended?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <db7ikfrvqkz6ovmpsaahkwozdizeq34ev6nhnxaldwlhbklx7x@vxl5e6hu2c6e>
Date: Wed, 17 Sep 2025 17:58:43 +0200
From: Jan Kara <jack@...e.cz>
To: "Richter, Rafael" <rafael.richter.extern@....de>
Cc: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: ext4: slow unmount with large clean page cache; is fsfreeze→umount recommended?

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@...e.com>
SUSE Labs, CR