2

How can I list all blocks on a device that are currently not being used by the filesystem? The filesystem in question is a btrfs RAID1 with two LUKS encrypted harddrives an Arch Linux.

I have tried fstrim /path/to/fs and log everything with blktrace. This actually works, but only if the hard drive supports TRIM - which is not the case here. (I have set up dmcrypt to allow TRIM).

The reasoning behind the question is this:

Two conventional hard-drives had been set up in a mdadm RAID with LVM+ext4 on top. Now those two hard-drives were set up with LUKS, btrfs RAID1 and data was written to this.

Unfortunately not everything had been backed up before the overwrite action. The hard drives have not been overwritten with random data before turning on LUKS, so the old data exists wherever nothing had been written yet in the current filesystem (I have verified this).

Now I am trying to recover as much as possible. My recovery strategy is the following:

Everything that is now being used by the btrfs filesystem can obviously not be the old data. So I want to find all blocks on the device that are currently not being used by btrfs. I then want to create an HD image the size of one those hard-drives, containing all the unused blocks. That would be my old data.

Actually, I don't really need to issue a real trim, I would just need to know what a TRIM would do. Or, simply find all blocks currently not used by the filesystem, which is my question.

Any way of doing that?

Siva
  • 9,077
Curly060
  • 21
  • And what about testdisk? Have you tried it? – Bob Jul 24 '18 at 11:56
  • Yes, but it doesn't really help in this situation. The two hard-disks were part of an mdadm raid, so they have the same data. The btrfs RAID1 now distributes the data differently on both drives, so different parts of the drives were overwritten (I have verified this). That's why I need to ask the filesystem which blocks are not used. I don't see how testdisk can help me here. – Curly060 Jul 24 '18 at 12:16
  • Try btrfs-debug-tree. Never used it, but I hope it's similar to ext2/3/4 dumpe2fs -x /dev/sdXn. Infact you need something like FIBMAP, I'm not sure it's compatible with btrfs. For ext2/3/4 even hdparm has --fibmap option as FIBMAP implementation. Also check if something like debugfs is available to btrfs. – Bob Jul 24 '18 at 13:08
  • hdparm --fibmap /path/to/file bails out with 0,19: drive not found in /dev. Possibly because btrfs runs on an encrypted device. btrfs-debug-tree prints out a lot of (too much?) information. I haven't been able to find logic in the output yet. I might be able to figure it out using the docs and source, but that will consume days. I will try find /path/to/btrfsmount -type f -exec sh -c 'cat {} > /dev/null' and log the result of this with blktrace. Still can't believe that there is no easy way of doing this. Thanks so far for the help! – Curly060 Jul 25 '18 at 11:07
  • Check this: https://unix.stackexchange.com/questions/458293/fastest-way-to-count-zero-bytes-on-a-partition – Bob Jul 25 '18 at 11:11

0 Answers0