#StackBounty: #data-recovery #trim Is it possible to recover data from a Western Digital TRIM supporting disks (not SSD) after quick fo…

Bounty: 50

I have a western digital blue disk, which is one of the SMR variations. I’ve heard that they support TRIM command. The disk is accidentally quick formatted on Windows 10, and now seems to be all zero. But, I’m wondering, for a disk it would take illogical amount of effort to actually set all sectors (1TB) to zero. I don’t really understood how TRIM applies to such disks, and suppose to see something like a list of safely deletable sectors or something like that in the disk’s firmware.

So the question is: Is there any way to recover the data from my disk? Including firmware tweaks or hardware tweaks?

Get this bounty!!!

#StackBounty: #ext4 #ssd #cryptsetup #trim #fstrim independently verify that TRIM indeed works on SSD

Bounty: 200

I have a LUKS partition /dev/sda1 which I luksOpen with --allow-discards:

cryptsetup --allow-discards luksOpen /dev/sda1 root

I then mount the ext4 filesystem with discard option:

grep /dev/mapper/root /proc/mounts
/dev/mapper/root / ext4 ro,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl 0 0

I then trim free space on the mounted partition:

fstrim -v /

with df, I see / has 80% free space.
That means that on /dev/sda1, 80% of the disk are binary zeros.

If I clone the image with cat

cat /dev/sda1 > sda1.img

and compress the image with xz, I would expect all the zeros on the disk to be compressed. Since the 20% of the data on the disk is encrypted, it should look like random and be uncompressible. Therefore, the xz-compressed image should be aprox. 20% of the raw size.

However, the resulting xz-compressed image is approximately same size as the raw original.

Is my reasoning correct?

Why does not my theory translate into practice ?

Get this bounty!!!