Does apfs Object Maps B-tree has internal copies (or old versions)?

[poppyer9]

bash-3.2# fsck_apfs /dev/disk3s1 Checking the container superblock. Checking the checkpoint with transaction ID 3938710. Checking the EFI jumpstart record. Checking the space manager. Checking the space manager free queue trees. Checking the object map. Checking the encryption key structures. Checking volume /dev/rdisk3s1. Checking the APFS volume superblock. The volume OSX1015 - Data was formatted by newfs_apfs (748.77.11) and last modified by apfs_kext (1933.80.3). Checking the object map. error: (oid 0x375ac2) om: btn: invalid o_type (0x4000000b, expected 0x40000003) error: (oid 0x375ac2) om: btn: invalid o_subtype (0x0, expected 0xb) Object map is invalid. The volume /dev/disk3s1 could not be verified completely.

I examined (oid 0x375ac2), it seems that node get wiped. this node corresponded to /Users, therefore most important data is there.

a4 3e 58 73 98 16 e7 c2 5a 37 00 00 00 00 00 dd 0d 3c 00 00 00 00 00 0b 00 00 40 00 00 00 00 : �>Xs���Z7�
00 00 00 00 00 00 00 00 02 00 00 40 02 00 00 40 c3 5a 37 00 00 00 00 00 00 00 00 00 00 00 00 00 : @@�Z7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :

Is there another (or older) copy in APFS that I can recover from? It seems odd that APFS only have 1 copy of ObjectMap?

[poppyer9]

from explore-omap-tree

• 20: OID = 0x14460 || XID = 0x3c0ae1 || Target child node = 0x1c4f86

• 21: OID = 0x144ce || XID = 0x1b0 || Target child node = 0x3734a8

• 22: OID = 0x144d2 || XID = 0x1b0 || Target child node = 0x3757a5

• 23: OID = 0x14540 || XID = 0x1b0 || Target child node = 0x1c570a

• 24: OID = 0x145b9 || XID = 0x3c0e37 || Target child node = 0x1c4eff

• 25: OID = 0x1463e || XID = 0x36c0e3 || Target child node = 0x1c58c3

• 26: OID = 0x14839 || XID = 0x245c || Target child node = 0x375ac2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This child node is the problem, so 0x14839~0x14924 is lost. but I don't know where to find it's backup or if any exists?

• 27: OID = 0x14925 || XID = 0x151bbc || Target child node = 0x1c4edb

• 28: OID = 0x14983 || XID = 0x3c1600 || Target child node = 0x377c1f

• 29: OID = 0x149fb || XID = 0x3b8c14 || Target child node = 0x1c09c7

• 30: OID = 0x14a91 || XID = 0x27a11 || Target child node = 0x1c0a8a

• 31: OID = 0x14b0f || XID = 0x3c18e3 || Target child node = 0x1c4f94

• 32: OID = 0x14bc2 || XID = 0x4acb || Target child node = 0x374f98

[jivanpal]

Yes, old instances of objects should still be present on disk if TRIM hasn't already got to them, but fsck_apfs sadly won't find these for you or repair the filesystem accordingly. The drat search command planned for the next version should be able to find these, but the existing code is not intended for general use. You can have a look at src/commands/search.c if you are interested, though.

Unfortunately I do not have time currently to provide personalised guidance, but the discussion in #12 may be helpful to you.