Prove that shred does not erase an SSD

Steps

1. Make a plain filesystem on the image and mount it (mkfs.ext4 -q /tmp/disk.img, mkdir -p /mnt/lab, mount -o loop /tmp/disk.img /mnt/lab). Write a file containing MARKER, run sync, delete the file, and umount /mnt/lab. Show that the content is still recoverable from the raw image with grep -ac MARKER /tmp/disk.img. Deletion frees the inode, not the blocks. The sync matters: ext4 delays allocating blocks for new data, and a file deleted before its data is written back never reaches the disk at all, so the grep finds nothing and proves nothing.
2. Mount it again, write a second file containing SHREDMARKER, sync, run shred -u on it, unmount, and grep the raw image for SHREDMARKER. On this setup it is gone: ext4 on a plain file overwrites in place, which is exactly the magnetic-disk assumption shred makes. Now reason through why a real SSD breaks it -- the controller remaps every write to fresh cells (wear levelling), so the overwrite lands somewhere new and the old cells keep the data until the controller gets round to erasing them. Nothing in the operating system can see or address those cells.
3. State the conclusion: shred was designed for magnetic disks where a write replaces a sector, and gives no guarantee on flash whose controller chooses where writes land.
4. Now do it the reliable way. Put the passphrase in a key file so the Verify can use it -- printf 'lab-passphrase' > /tmp/lab.key -- then cryptsetup luksFormat -q --key-file /tmp/lab.key /tmp/disk.img, cryptsetup open --key-file /tmp/lab.key /tmp/disk.img lab, make a filesystem on /dev/mapper/lab, mount it, write a file containing LUKSMARKER, sync, and confirm you can read it back. Unmount and cryptsetup close lab. Grep the raw image for LUKSMARKER: zero, because the device only ever held ciphertext. (Grep for MARKER too. luksFormat rewrites only the header at the front of the image, so the plaintext from step 1 may still be there -- encrypting a disk that once held plaintext does not remove the plaintext. That is why the advice is to encrypt from first use.)
5. Destroy the data by destroying the key: cryptsetup luksErase -q /tmp/disk.img. The header and the ciphertext are still there -- cryptsetup isLuks /tmp/disk.img still succeeds -- but every key slot is gone, so the correct passphrase no longer opens it. It took an instant, and nothing in the payload was overwritten.
6. Contrast the effort: erasing a 4TB encrypted disk this way is one fast command, where overwriting it three times is hours and still not guaranteed on flash.
7. Note the hardware alternative for an unencrypted disk: the drive's own secure-erase or sanitize command, which the firmware can apply to every cell including those the host cannot address.