https://bugzilla.kernel.org/show_bug.cgi?id=216007 Bug ID: 216007 Summary: XFS hangs in iowait when extracting large number of files Product: File System Version: 2.5 Kernel Version: 5.15.32 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: XFS Assignee: filesystem_xfs@xxxxxxxxxxxxxxxxxxxxxx Reporter: bugzkernelorg8392@xxxxxxxxx Regression: No Created attachment 301008 --> https://bugzilla.kernel.org/attachment.cgi?id=301008&action=edit output from dmesg after echo w > /proc/sysrq-trigger Overview: When I try to extract an uncompressed tar archive (2.6 milion files, 760.3 GiB in size) on newly created (empty) XFS file system, after first low tens of gigabytes extracted the process hangs in iowait indefinitely. One CPU core is 100% occupied with iowait, the other CPU core is idle (on 2-core Intel Celeron G1610T). I have kernel compiled with my .config file. When I try this with a more "standard" kernel, the problem is not reproducible. Steps to Reproduce: 1) compile the kernel with the attached .config 2) reboot with this kernel 3) create a new XFS filesystem on a spare drive (just mkfs.xfs -f <dev>) 4) mount this new file system 5) try to extract large amount of data there Actual results: After 20-40 GiB written, the process hangs in iowait indefinitely, never finishing the archive extraction. Expected Results: Archive extraction continues smoothly until done. Build Date & Hardware: 2022-05-01 on HP ProLiant MicroServer Gen8, 4GB ECC RAM Additional Information: No other filesystem tested with the same archive on the same hardware before or after this (ext2, ext3, ext4, reiserfs3, jfs, nilfs2, f2fs, btrfs, zfs) has shown this behavior. When I downgraded the kernel to 5.10.109, the XFS started working again. Kernel versions higher than 5.15 seem to be affected, I tried 5.17.1, 5.17.6 and 5.18.0-rc7, they all hang up after a few minutes. No error is reported to the system log or to dmesg when the process hangs. No error shows on stdout or stderr of the tar process either. This is not a SMR problem. None of the disks present in the test setup are SMR. All are CMR, and while they certainly are not brand new, they are all in good working condition. Attached is the dmesg output after issuing this command: echo w > /proc/sysrq-trigger More could be found here: https://forums.gentoo.org/viewtopic-p-8709116.html -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
