zfs-2.3.0-rc3: 100% CPU load from ZFS kernel theads and written files were lost

[x64-Linux-Builder]

System information

Type	Version/Name
Distribution Name	Fedora
Distribution Version	41
Kernel Version	6.11.8-300.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Nov 14 20:37:39 UTC 2024 x86_64 GNU/Linux
Architecture	x86_64
OpenZFS Version	zfs-2.3.0-rc3

Describe the problem you're observing

100% CPU load from ZFS kernel theads on a fresh install of RC3.

Describe how to reproduce the problem

Seteup:

System is an Mini PC (Beelin Mini-S) using an Intel N95 CPU, 8GB RAM

• System with no special config updated for FC41
• Downloaded the zfs-2.3.0-rc3 tarball from github
• configure (no options passed) ; make; sudo make install
• USB3.0 Hard-Disk (rotating spindle) connected, created one big partition, nothing mounted, nothing else on the disk.

System is idle, has no load.

• zpool create greenchilli /dev/disk/by-label/greenchilli
• zfs create -o mountpoint=/greenchilli greenchilli/fs1
• echo hi >/greenchilli/new.txt

Shortly afterwards

• the z_wr_iss and z_wr_int kernel threads (3 each) started eating 33% CPU each,
• But no I/O by processes

The 100% CPU load came and went, 100% for some minutes, than briefly gone; repeat

• Rebooted a few times, issue persisted.
• Copied data on the volume.
• After a forced reboot, the systemctl restart zfs-import-scan.service was stuck after boot (to scan for the pool).
• After another forced reboot, only original /new.txt was found after mounting it, the other data was no longer on the fs.

Include any warning/errors/backtraces from the system logs

No Oopses or other errors or warnings found in the log.

[amotin]

The z_wr_iss and z_wr_int kernel threads are block write issue and completion threads. They should do nothing if there is no data to write. If there is small activity on the pool, they might indeed spike every few seconds due to transactional nature of ZFS. But for them to eat significant amount of CPU there must be significant amount of data.

[bernhardkaindl]

Thanks, that would be usual, logical behaviour indeed. I was in disbelief.
I would not have reported it if I hadn't been sitting in front of it and seen it first-hand.
I logged in locally on the KDE Plasma desktop and was stunned as it was a fresh, empty fs.
If I had another ZFS on another host, I would have assumed I must have looked at the wrong host.

My only possible explanation is that ZFS might have scrubbed the unallocated disk blocks.
Besides some locking issues that only happen on very slow/weak CPUs like the N95 CPU.
Is that possible? I started the zed service shortly before the spinning of the ktreads started.