-
Notifications
You must be signed in to change notification settings - Fork 5.2k
ext4 regression causes huge load #5097
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
Thanks - that's reverted on the current branches. |
kernel: dtoverlays: Add nohdmi options to vc4-kms-v3d overlays raspberrypi/linux#5099 kernel: overlays: Make more overlays runtime-capable See: raspberrypi/linux#5101 kernel: overlays: Mark more overlays as Pi4-specific kernel: Revert ext4: make mb_optimize_scan performance mount option work with extents See: raspberrypi/linux#5097 kernel: configs: Enable IIO software trigger modules See: raspberrypi/linux#4984 kernel: configs: Enable IP_VS_IPV6 (for loadbalancing) See: raspberrypi/linux#2860 kernel: configs: Enable CEPH_FS=m See: raspberrypi/linux#2916 firmware: arm_loader: initramfs over NVME fix See: #1731
kernel: dtoverlays: Add nohdmi options to vc4-kms-v3d overlays raspberrypi/linux#5099 kernel: overlays: Make more overlays runtime-capable See: raspberrypi/linux#5101 kernel: overlays: Mark more overlays as Pi4-specific kernel: Revert ext4: make mb_optimize_scan performance mount option work with extents See: raspberrypi/linux#5097 kernel: configs: Enable IIO software trigger modules See: raspberrypi/linux#4984 kernel: configs: Enable IP_VS_IPV6 (for loadbalancing) See: raspberrypi/linux#2860 kernel: configs: Enable CEPH_FS=m See: raspberrypi/linux#2916 firmware: arm_loader: initramfs over NVME fix See: raspberrypi/firmware#1731
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
Hi, just a short update on this issue after a lot of work. There is a patch series which hopefully will be applied soon: |
Thanks for info. I'm guessing it will be backported to linux-5.15.y and I'll know to revert the revert when the conflict comes. |
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi/linux#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: #5097 Signed-off-by: Phil Elwell <[email protected]>
@popcornmix No, need to revert this patch in rpi-5.15.y anymore. The real fixes has been backported at the end of September: |
…work with extents"" This reverts commit e05a335. The revert should no longer be necessary after upstream: ext4: avoid unnecessary spreading of allocations among groups See: #5097 Signed-off-by: Dom Cobley <[email protected]>
Reverted the revert. Thanks for heads up. |
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
…h extents" This reverts commit 3c65b73. The reverted commit is likely to also be reverted upstream, but with a performance regression like this I don't want to wait for that. See: raspberrypi#5097 Signed-off-by: Phil Elwell <[email protected]>
Describe the bug
Recently users of Arch Linux ARM complained about huge load on IO task like unpacking bigger tar archives starting with Linux 5.18. Because the error descriptions was mixed with SD cards issues it was hard to identify and i suspect the ext4 partition must also be in a "used" state.
Last week i found a good scenario to bisect the issue. Here is the related upstream bug report:
https://marc.info/?l=linux-ext4&m=165815090631395&w=3
Unfortunately the offending change 3c65b73 has been backported to Linux 5.15.33, but a revert of the commit should fix the problem.
Steps to reproduce the behaviour
Expected behavior:
Observed behavior:
Device (s)
Raspberry Pi 4 Mod. B
System
Kernel version: 5.15.55
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: