Open wmertens opened 3 weeks ago
What version? the EEXIST makes me think you might be running an old one
Apologies, should have added that from the start, looks like 1.7:
$ bcachefs version
1.7.0-unstable-2024-05-09
$ sudo bcachefs show-super /dev/disk/by-partlabel/root
Device: (unknown device)
External UUID: 82ace8da-b608-450f-a397-f1b30c838560
Internal UUID: 98c4b18b-c7de-4491-a600-d81d09cee632
Magic number: c68573f6-66ce-90a9-d96a-60cf803df7ef
Device index: 0
Label:
Version: 1.7: mi_btree_bitmap
Version upgrade complete: 1.7: mi_btree_bitmap
Oldest version on disk: 1.4: member_seq
Created: Wed Apr 17 11:58:24 2024
Sequence number: 258
Time of last write: Wed Jun 19 14:43:33 2024
Superblock size: 5.79 KiB/1.00 MiB
Clean: 0
Devices: 1
Sections: members_v1,replicas_v0,disk_groups,clean,journal_seq_blacklist,journal_v2,counters,members_v2,errors,ext,downgrade
Features: zstd,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
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 [ro] panic
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
compression: zstd
background_compression: none
str_hash: crc32c crc64 [siphash]
metadata_target: none
foreground_target: none
background_target: none
promote_target: none
erasure_code: 0
inodes_32bit: 1
shard_inode_numbers: 1
inodes_use_key_cache: 1
gc_reserve_percent: 8
gc_reserve_bytes: 0 B
root_reserve_percent: 0
wide_macs: 0
acl: 1
usrquota: 0
grpquota: 0
prjquota: 0
journal_flush_delay: 1000
journal_flush_disabled: 0
journal_reclaim_delay: 100
journal_transaction_names: 1
version_upgrade: [compatible] incompatible none
nocow: 0
members_v2 (size 152):
Device: 0
Label: root (0)
UUID: 47c12cb4-d0d7-4220-b545-35c26f85eb40
Size: 837 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: 1714424
Last mount: Wed Jun 19 14:43:31 2024
Last superblock write: 258
State: rw
Data allowed: journal,btree,user
Has data: journal,btree,user
Btree allocated bitmap blocksize: 32.0 MiB
Btree allocated bitmap: 0000000000000000000000001111111111111111111111111111111111111111
Durability: 1
Discard: 0
Freespace initialized: 1
errors (size 40):
inode_multiple_links_but_nlink_0 236 Mon May 27 08:03:13 2024
inode_wrong_nlink 192 Mon May 27 08:04:01 2024
$ uname -a
Linux wmertens-nixos 6.9.4 #1-NixOS SMP PREEMPT_DYNAMIC Wed Jun 12 09:39:59 UTC 2024 x86_64 GNU/Linux
6.9.4 is recent enough, something odd is going on.
Could you send me a metadata dump? Jump on IRC (irc.oftc.net#bcache) and send it to me via magic wormhole.
Also, from your kernel source tree, ./scripts/faddr2line vmlinux inode_insert5+0x14e/0x1f0
@koverstreet that needs to happen offline, right? How big should I expect the metadata to be? I'll have to do it from a rescue image.
correct bcachefs fs usage should give you an idea - look at the amount of metadata you have
Update on this? I want to get your fs back up and running :)
Is the metadata dump going to be practical?
Turns out that bare EEXIST is from us; I'd fixed it in master, but that wasn't in 6.9.
I should be able to fix that today.
ah - so everything actually works and I have no visible corruption, only the messages and the dangling inodes.
So if you no longer need the metadata that's good news because it is quite an ordeal for me. I also need to figure out how to get faddr2line from nixpkgs.
fsck is still giving you EEXIST when it tries to repair?
This pops up quite often.
When I try to online repair: