bcachefs not rebalancing foreground to background
I have recently copied some of my data to bcachefs. However I noticed the foreground is now full, but there are no rebalance task running after idling for 4 hours, resulting in low write performance as everything goes to background.
bcachefs show-super:
Device: QEMU HARDDISK
External UUID: 50c1fb36-722d-4724-81cb-d765a32e432a
Internal UUID: f9c7ed7c-2465-4b69-b97c-0e6eae792e3f
Magic number: c68573f6-66ce-90a9-d96a-60cf803df7ef
Device index: 1
Label: (none)
Version: 1.25: extent_flags
Incompatible features allowed: 1.25: extent_flags
Incompatible features in use: 0.0: (unknown version)
Version upgrade complete: 1.25: extent_flags
Oldest version on disk: 1.25: extent_flags
Created: Sun Apr 13 11:22:02 2025
Sequence number: 32
Time of last write: Mon Apr 14 08:08:10 2025
Superblock size: 4.77 KiB/1.00 MiB
Clean: 0
Devices: 2
Sections: members_v1,replicas_v0,disk_groups,clean,journal_v2,counters,members_v2,errors,ext,downgrade
Features: new_siphash,inline_data,new_extent_overwrite,btree_ptr_v2,extents_above_btree_updates,btree_updates_journalled,new_varint,journal_no_flush,alloc_v2,extents_across_btree_nodes,incompat_version_field
Compat features: alloc_info,alloc_metadata,extents_above_btree_updates_done,bformat_overflow_done
Options:
block_size: 512 B
btree_node_size: 256 KiB
errors: continue [fix_safe] panic ro
write_error_timeout: 30
metadata_replicas: 1
data_replicas: 1
metadata_replicas_required: 1
data_replicas_required: 1
encoded_extent_max: 64.0 KiB
metadata_checksum: none [crc32c] crc64 xxhash
data_checksum: none [crc32c] crc64 xxhash
checksum_err_retry_nr: 3
compression: none
background_compression: none
str_hash: crc32c crc64 [siphash]
metadata_target: ssd
foreground_target: ssd
background_target: hdd
promote_target: none
erasure_code: 0
inodes_32bit: 1
shard_inode_numbers_bits: 2
inodes_use_key_cache: 1
gc_reserve_percent: 5
gc_reserve_bytes: 0 B
root_reserve_percent: 0
wide_macs: 0
promote_whole_extents: 1
acl: 1
usrquota: 0
grpquota: 0
prjquota: 0
degraded: [ask] yes very no
journal_flush_delay: 1000
journal_flush_disabled: 0
journal_reclaim_delay: 100
journal_transaction_names: 1
allocator_stuck_timeout: 30
version_upgrade: [compatible] incompatible none
nocow: 1
single_device: 0
members_v2 (size 304):
Device: 0
Label: ssd (0)
UUID: 458fcda6-5250-4596-8748-fdf24bb382ac
Size: 120 GiB
read errors: 0
write errors: 0
checksum errors: 0
seqread iops: 0
seqwrite iops: 0
randread iops: 0
randwrite iops: 0
Bucket size: 512 KiB
First bucket: 0
Buckets: 245758
Last mount: Sun Apr 13 11:23:21 2025
Last superblock write: 32
State: rw
Data allowed: journal,btree,user
Has data: journal,btree,user
Btree allocated bitmap blocksize: 4.00 MiB
Btree allocated bitmap: 0000000000010000000000000000000000000000000000000000001000000011
Durability: 1
Discard: 0
Freespace initialized: 1
Device: 1
Label: hdd (1)
UUID: d011ed64-8690-402f-b100-6be4ebdd1857
Size: 10.7 TiB
read errors: 0
write errors: 0
checksum errors: 0
seqread iops: 0
seqwrite iops: 0
randread iops: 0
randwrite iops: 0
Bucket size: 512 KiB
First bucket: 0
Buckets: 22528000
Last mount: Sun Apr 13 11:23:21 2025
Last superblock write: 32
State: rw
Data allowed: journal,btree,user
Has data: btree,user
Btree allocated bitmap blocksize: 128 MiB
Btree allocated bitmap: 0000000000000010000000000000000000000000000000000000000000000000
Durability: 1
Discard: 0
Freespace initialized: 1
errors (size 8):
fs usage:
root@1814:~# bcachefs fs usage /data -h
Filesystem: 50c1fb36-722d-4724-81cb-d765a32e432a
Size: 10.3 TiB
Used: 5.83 TiB
Online reserved: 1.00 KiB
Data type Required/total Durability Devices
btree: 1/1 1 [sdb2] 2.05 GiB
btree: 1/1 1 [sda] 1.69 GiB
user: 1/1 1 [sdb2] 117 GiB
user: 1/1 1 [sda] 5.71 TiB
Btree usage:
extents: 905 MiB
inodes: 6.00 MiB
dirents: 2.00 MiB
alloc: 1.68 GiB
subvolumes: 256 KiB
snapshots: 256 KiB
lru: 256 KiB
freespace: 256 KiB
need_discard: 768 KiB
backpointers: 1.16 GiB
bucket_gens: 256 KiB
snapshot_trees: 256 KiB
deleted_inodes: 256 KiB
logged_ops: 256 KiB
rebalance_work: 256 KiB
accounting: 1.50 MiB
hdd (device 1): sda rw
data buckets fragmented
free: 5.01 TiB 10518108
sb: 3.00 MiB 7 508 KiB
journal: 4.00 GiB 8192
btree: 1.69 GiB 3512
user: 0 B 0
cached: 0 B 0
parity: 0 B 0
stripe: 0 B 0
need_gc_gens: 0 B 0
need_discard: 0 B 0
unstriped: 0 B 0
capacity: 10.7 TiB 22528000
ssd (device 0): sdb2 rw
data buckets fragmented
free: 1.00 MiB 2
sb: 3.00 MiB 7 508 KiB
journal: 960 MiB 1919
btree: 2.05 GiB 4207
user: 0 B 0
cached: 0 B 0
parity: 0 B 0
stripe: 0 B 0
need_gc_gens: 0 B 0
need_discard: 0 B 0
unstriped: 0 B 0
capacity: 120 GiB 245758
Can you hop on IRC? you've been turning up quite a few, it'll be quicker working through them there :)
Confirm its fixed in 1f1ac5fc586bb93381f40d47f3f781ffd835e483
FYI: I believe current behavior will now be to send nocow writes directly to the background target once the extent's been moved there, we might want to tweak this some more
FYI: I believe current behavior will now be to send nocow writes directly to the background target once the extent's been moved there, we might want to tweak this some more
@koverstreet should I open a separate ticket to track that? :)