From: bugzilla-daemon@kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 217965] ext4(?) regression since 6.5.0 on sata hdd
Date: Tue, 17 Oct 2023 10:45:29 +0000 [thread overview]
Message-ID: <bug-217965-13602-A9FNXbUyFf@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-217965-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=217965
Eduard Kohler (glandvador@yahoo.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glandvador@yahoo.com
--- Comment #15 from Eduard Kohler (glandvador@yahoo.com) ---
I encounter the same issue on a stock fedora 37 kernel
# uname -a
Linux xxx.net 6.4.16-100.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Sep 13 18:22:38
UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
The issue seems to be present also on brtfs partitions, as mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=2242391
In my case, I have an EXT4 partition over an mdadm raid 1 array of two HDD.
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Feb 24 21:40:33 2013
Raid Level : raid1
Array Size : 3906118928 (3.64 TiB 4.00 TB)
Used Dev Size : 3906118928 (3.64 TiB 4.00 TB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Tue Oct 17 12:05:22 2023
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
Name : xxx.net:0 (local to host xxx.net)
UUID : 25070e74:b2ac1695:46ee20f9:7e8d1e05
Events : 402440
Number Major Minor RaidDevice State
3 8 17 0 active sync /dev/sdb1
2 8 33 1 active sync /dev/sdc1
dumpe2fs -h /dev/md0p1
dumpe2fs 1.46.5 (30-Dec-2021)
Filesystem volume name: <none>
Last mounted on: /home
Filesystem UUID: 4df09a03-d8ef-4cef-a64d-cefde4823fc2
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg
dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 244137984
Block count: 976529232
Reserved block count: 48826457
Overhead clusters: 15373546
Free blocks: 545717412
Free inodes: 243040909
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 791
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stride: 32745
Flex block group size: 16
Filesystem created: Sun Feb 24 22:13:52 2013
Last mount time: Mon Oct 16 21:06:57 2023
Last write time: Mon Oct 16 21:06:57 2023
Mount count: 6
Maximum mount count: -1
Last checked: Sat Oct 7 16:27:02 2023
Check interval: 0 (<none>)
Lifetime writes: 238 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 13509593
Default directory hash: half_md4
Directory Hash Seed: af37e79f-0457-4318-9c5d-840dc2f60bce
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Total journal size: 128M
Total journal blocks: 32768
Max transaction length: 32768
Fast commit length: 0
Journal sequence: 0x003bc716
Journal start: 1
# df /dev/md0p1
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0p1 3844622744 1661757340 1987543192 46% /home
# mount |grep md0
/dev/md0p1 on /home type ext4 (rw,relatime,seclabel,stripe=32745)
In order to trig the 100% CPU on one core, a simple
# for i in {0001..0200}; echo "some text" > "file_${i}.txt"
is enough. This will bring the kworker/flush at 100 % for around 90 seconds.
This time is dependent of the number of created files. Trying to delete these
files is more or less impossible.
On the same setup I have a small SSD used for system installation. The same
test doesn't bring the kworker/flush behaviour.
# dumpe2fs -h /dev/sda3
dumpe2fs 1.46.5 (30-Dec-2021)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: 589968d6-2283-4903-8699-1b23f5c341a5
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg
dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 848640
Block count: 3390208
Reserved block count: 169510
Free blocks: 1823000
Free inodes: 735742
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 827
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8160
Inode blocks per group: 510
Flex block group size: 16
Filesystem created: Sun Apr 6 00:00:12 2014
Last mount time: Mon Oct 16 21:06:53 2023
Last write time: Mon Oct 16 21:06:47 2023
Mount count: 437
Maximum mount count: -1
Last checked: Sun Apr 6 00:00:12 2014
Check interval: 0 (<none>)
Lifetime writes: 1791 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 130778
Default directory hash: half_md4
Directory Hash Seed: 7d17214b-9585-4370-8c06-4236e449fa7f
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Total journal size: 128M
Total journal blocks: 32768
Max transaction length: 32768
Fast commit length: 0
Journal sequence: 0x0114205c
Journal start: 8194
# mount |grep sda3
/dev/sda3 on / type ext4 (rw,noatime,seclabel)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2023-10-17 10:45 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-02 8:10 [Bug 217965] New: ext4(?) regression since 6.5.0 on sata hdd bugzilla-daemon
2023-10-02 8:52 ` [Bug 217965] " bugzilla-daemon
2023-10-02 8:56 ` bugzilla-daemon
2023-10-02 8:57 ` bugzilla-daemon
2023-10-02 15:22 ` bugzilla-daemon
2023-10-02 15:55 ` bugzilla-daemon
2023-10-03 6:50 ` bugzilla-daemon
2023-10-03 6:57 ` bugzilla-daemon
2023-10-03 11:04 ` bugzilla-daemon
2023-10-03 13:42 ` bugzilla-daemon
2023-10-03 14:23 ` bugzilla-daemon
2023-10-04 12:44 ` bugzilla-daemon
2023-10-04 17:23 ` bugzilla-daemon
2023-10-11 7:53 ` bugzilla-daemon
2023-10-11 16:07 ` bugzilla-daemon
2023-10-11 22:23 ` bugzilla-daemon
2023-10-17 10:45 ` bugzilla-daemon [this message]
2023-10-17 10:52 ` bugzilla-daemon
2023-10-20 10:24 ` bugzilla-daemon
2023-10-21 10:07 ` bugzilla-daemon
2023-11-13 22:46 ` bugzilla-daemon
2023-11-14 5:55 ` bugzilla-daemon
2023-11-14 6:47 ` bugzilla-daemon
2023-11-14 8:22 ` bugzilla-daemon
2023-11-14 10:29 ` bugzilla-daemon
2023-11-15 4:06 ` bugzilla-daemon
2023-11-15 17:27 ` bugzilla-daemon
2023-11-15 22:39 ` bugzilla-daemon
2023-11-16 3:15 ` bugzilla-daemon
2023-11-16 4:05 ` bugzilla-daemon
2023-11-16 4:31 ` bugzilla-daemon
2023-11-16 4:33 ` bugzilla-daemon
2023-11-16 19:33 ` bugzilla-daemon
2023-11-17 0:01 ` bugzilla-daemon
2023-11-17 0:44 ` bugzilla-daemon
2023-11-17 1:39 ` bugzilla-daemon
2023-11-17 1:40 ` bugzilla-daemon
2023-11-17 15:39 ` bugzilla-daemon
2023-11-17 23:52 ` bugzilla-daemon
2023-11-17 23:53 ` bugzilla-daemon
2023-11-17 23:57 ` bugzilla-daemon
2023-11-18 12:10 ` bugzilla-daemon
2023-11-18 13:17 ` bugzilla-daemon
2023-11-20 6:11 ` bugzilla-daemon
2023-11-20 8:48 ` bugzilla-daemon
2023-11-27 17:31 ` bugzilla-daemon
2023-12-03 7:33 ` bugzilla-daemon
2023-12-15 11:27 ` bugzilla-daemon
2023-12-23 0:56 ` bugzilla-daemon
2023-12-23 1:48 ` bugzilla-daemon
2023-12-23 12:46 ` bugzilla-daemon
2023-12-23 14:22 ` bugzilla-daemon
2023-12-23 15:47 ` bugzilla-daemon
2023-12-29 20:35 ` bugzilla-daemon
2023-12-29 20:51 ` bugzilla-daemon
2023-12-29 21:05 ` bugzilla-daemon
2023-12-29 22:11 ` bugzilla-daemon
2023-12-29 22:13 ` bugzilla-daemon
2023-12-29 23:07 ` bugzilla-daemon
2023-12-29 23:22 ` bugzilla-daemon
2024-01-02 4:44 ` bugzilla-daemon
2024-01-02 6:44 ` bugzilla-daemon
2024-01-04 5:38 ` bugzilla-daemon
2024-01-04 22:20 ` bugzilla-daemon
2024-01-06 2:11 ` bugzilla-daemon
2024-01-06 3:18 ` bugzilla-daemon
2024-01-07 2:56 ` bugzilla-daemon
2024-02-07 11:44 ` bugzilla-daemon
2024-03-12 20:27 ` bugzilla-daemon
2024-03-17 11:58 ` bugzilla-daemon
2024-03-18 4:45 ` bugzilla-daemon
2024-03-20 6:46 ` bugzilla-daemon
2024-03-23 8:53 ` bugzilla-daemon
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=bug-217965-13602-A9FNXbUyFf@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--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 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.