Closed Mjasnik closed 10 months ago
This was likely the bug referenced here: https://lore.kernel.org/linux-bcachefs/20231019183803.njsjs4sz7p4zpyfc@moria.home.lan/T/#t
It's fixed in master now - please try on the latest version and reopen if you still have issues
Thanks, it looks like this is fixed.
# BCACHEFS
rsync --info=progress2 -a /mnt/DATA/WinePrefixes/* /mnt/BIGDATA2.BCH/ && time sync
243.381.299.244 99% 303,95MB/s 0:12:43 (xfr#119150, to-chk=0/136841)
real 0m46,078s
user 0m0,001s
sys 0m0,004s
Read speed improved a little too, still slowest of the 4 I tested, but improved.
dd if="/mnt/BIGDATA2.BCH/GOG.Galaxy/drive_c/Program Files (x86)/GOG Galaxy/Games/Cyberpunk 2077/archive/pc/content/basegame_4_appearance.archive" of=/dev/null bs=16M
967+1 records in
967+1 records out
16232243200 bytes (16 GB, 15 GiB) copied, 71,6984 s, 226 MB/s
Overview At first I planned to use bcachefs on whole 2x3TB partitions in raid0, but I encountered severe performance issues with writing to disk. kworker thread flush-bcachefs uses 100% CPU almost all the time. The speed slowly declines from ~ 300MB/s to 15MB/s at the end. The computer is Ryzen 5800X3D, 48GB of RAM, source disk is NVME, so plenty of read speed.
Notes I have read that bcachefs is used with large DBs and so on and noone have really created yet bug reports about performance, maybe there is a configuration issue on my part, however the speed is bad.
Tests For testing the issue, I split each disk into 4 partitions each to test out various FS in raid0 to rule out disk issues. Since I performed them, here are the results. The folder I synced is filled with games, this means a lot of small files + a lot of big ones too.
I had set up raid0 (this is the order of partitions on disks):
I used the following commands to create raid:
I performed the same write test on every FS. MDADM
BCACHEFS
BTRFS
ZFS
I performed the same read test on every FS.
Version Commit hash 786558a, compiled on 18.10.2023 from master. I have tested the patch from https://github.com/CachyOS/kernel-patches/tree/master/6.5/misc, which I assume, at the time was the same version as of hash 786558a, there was no difference in performance.
Kernel options:
Generic info