bcachefs
bcachefs copied to clipboard
koverstreet
fsck shows "key in deleted snapshot extents" errors
When I run an offline fsck on my bcachefs root I see the following error logs every time:
kernel: bcachefs (dm-3): check_extents...
kernel: bcachefs (dm-3): key in deleted snapshot extents u64s 5 type whiteout 980655:209:4294967275 len 0 ver 0, deleting
kernel: bcachefs (dm-3): key in deleted snapshot extents u64s 5 type whiteout 980665:3083:4294967275 len 0 ver 0, deleting
It looks like there's some error that fsck isn't able to fix? It still mounts successfully, just with those error logs.
I'm running bcachefs-dkms 1.31.6 on kernel 6.16.8-arch3.
show-super
External UUID: 5c9366a1-75bb-4196-802c-8484ad95b790
Internal UUID: 74111912-ea0e-4d3d-b0b3-d731622013d2
Magic number: c68573f6-66ce-90a9-d96a-60cf803df7ef
Device index: 0
Label: (none)
Version: 1.31: btree_node_accounting
Incompatible features allowed: 1.31: btree_node_accounting
Incompatible features in use: 1.29: extent_snapshot_whiteouts
Version upgrade complete: 1.31: btree_node_accounting
Oldest version on disk: 1.28: inode_has_case_insensitive
Created: Sat May 17 22:06:30 2025
Sequence number: 4993
Time of last write: Sat Oct 4 09:52:01 2025
Superblock size: 5.35 KiB/1.00 MiB
Clean: 0
Devices: 1
Sections: replicas_v0,clean,journal_seq_blacklist,journal_v2,counters,members_v2,errors,ext,downgrade,recovery_passes
Features: journal_seq_blacklist_v3,reflink,new_siphash,inline_data,new_extent_overwrite,btree_ptr_v2,extents_above_btree_updates,btree_updates_journalled,reflink_inline_data,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,no_stale_ptrs
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: none
foreground_target: none
background_target: none
promote_target: none
erasure_code: 0
casefold: 0
inodes_32bit: 1
shard_inode_numbers_bits: 4
inodes_use_key_cache: 1
gc_reserve_percent: 8
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: 0
rebalance_on_ac_only: 0
errors (size 104):
bkey_in_deleted_snapshot 117 Sat Oct 4 09:51:52 2025
accounting_key_nr_counters_wrong 63 Fri Sep 19 08:39:31 2025
accounting_key_underflow 2 Thu Sep 18 22:32:28 2025
vfs_bad_inode_rm 36 Tue Jul 29 18:54:11 2025
inode_wrong_nlink 4 Sat Jul 12 15:05:47 2025
inode_dir_has_nonzero_i_size 484 Sun Jun 29 22:59:32 2025
Device 0: /dev/dm-3 (unknown model)
Label: (none)
UUID: 9326abd6-224d-4b6e-b2a0-1424d114b9dd
Size: 200 GiB
read errors: 0
write errors: 0
checksum errors: 1
seqread iops: 0
seqwrite iops: 0
randread iops: 0
randwrite iops: 0
Bucket size: 256 KiB
First bucket: 0
Buckets: 819200
Last mount: Sat Oct 4 09:51:39 2025
Last superblock write: 4993
State: rw
Data allowed: journal,btree,user
Has data: journal,btree,user
Btree allocated bitmap blocksize: 4.00 MiB
Btree allocated bitmap: 0000000001000000000000000000001000000000010000000001000000000111
Durability: 1
Discard: 1
Freespace initialized: 1
Resize on mount: 0
Can you take a metadata dump (bcachefs dump) while the FS is not mounted and in a state where the next offine FSCK will log those errors, and join the IRC channel so that we can debug this further? The metadata dump is likely to be very small for your FS.
