Being written as a quick and dirty tool in a time of need, practically the whole code is not commented. In the name of its maintainability and future development, it will be nice to have it document itself with proper documentation strings.

In order to be able to use py-zfs-rescue on pools created by modern OSes, the following two enhancements are needed:

• Support for block pointers with embedded data
• Support for ZPL attribute tables as an alternative to znode_phys_t (bonus data type 0x2c)

Hi, thanks so much for sharing this code.

I'm trying to extend it to perform block-level recovery (for when the metadata is too damaged to properly recurse the filesystem) - using a whole disk scan. But one issue I'm running into is that I can't see any way to extract a file/directory's object number from the DMU_OT_PLAIN_FILE_CONTENTS dnode etc. It doesn't seem to be in the SA attributes (you have the parent object number obviously, but that's only partially helpful).

The only way to get the object number seems to be to know the exact relative position of that dnode within the containing array. And if your metadata is corrupt or you only have a partial array, then I can't think of a reliable way to get the object number. Does anyboy have some ideas for this?

I find it really odd that they didn't embed the object number (and file name maybe) in the actual file dnode.

I try to recover a raidz array with 3 disks on zfslinux. It uses a
ashift parameter of 12 (4086 byte blocks) which is I think not handled
by py-zfs-rescue.
Can you point out which parts I have to change to make py-zfs-rescue
work with this ashift parameter?
As a test I'm using a losetup based pool with
zpool create datapool -f -o ashift=12 -O -O compression=lz4 -O normalization=formD raidz /dev/loop0 /dev/loop1 /dev/loop2
Adding lz4 compression support I think I can handle however the ashift parameter
seems to be hardcoded in different location to 9 and I'm not shure weather this parameter
is dependent on the type of data one is loading.
I created a dataset inside the testpool and tried to open it with py-zfs-rescue, however it is not
possible and failes when loading ..

 [+] Loading object set dnode from <[L0 DMU objset] 800L/800P DVA[0]=<0:e0000:2200> DVA[1]=<0:40de000:2200> DVA[2]=<0:809a000:2200> birth=34 fletcher4 off LE contiguous fill=50>
> Failed - unsupported operand type(s) for //: 'NoneType' and 'int'

zfs create datapool0/datadir (childsets) seems to be handled differently on FreeBSD. The child dataset is found in the ZAP but In the childdataset code in zfs_rescue.py child = mos[v] will return None. So child datasets are only working for linux.