Hello to all, while waiting amazon to ships all the component of my new pc, I was wondering, how does the shred utility relate to the "new" (for me) solid state drives?

Will it work the same, if used in combination of a "normal" filesystem, like ext3 or ext4?

Reading online, I found out that, given the "default" options of extX filesystem, it does work as advertised, even if they are journaling filesystems.

But how about the way sdds do physically works? will the good old shred utility still works?
As far as I know, it overwrite the file with random strings (default) then if the "-u" is passed, it will unlink the file and delete it in a unrecoverable way.

But will it apply to ssds too?

I don't think that will work on ssd's. Because as far as I know the logical blocks that are controlled by the proprietary controllers are dynamic on the actual chips. so it's not one on one logical block allocation like a traditional harddrive does.

I don't know what brand SSD you have, but with my Intel SSD's I can do a security erase with hdparm. (which will only take about a minute or maybe 2)


I do that like this:

(you can simply use the slack ware install disk to boot and use hdparm from there, or any portable/live linux like puppy linux)
***
prepare the drive: secure erasing drive
( dev/sda is my first drive, check yourself for correct device name on your system)

# hdparm -I /dev/sda
(if drive is in frozen state, unplug and plug, while system is running. drive should then say NOT frozen)

step 1 set a temp master password (will be lost after secure erase)

# hdparm --user-master u --security-set-pass slack /dev/sda

step 2 issue the erase disk command

# hdparm --user-master u --security-erase slack /dev/sda

****

But I'm not sure whether that works on every SSD. I think samsung has their own utilities for that. Just look on the term "secure erase" and your type of ssd.

1 members found this post helpful.

shred is totally pointless on an SSD for the simple reason that writing to an SSD block never overwrites the current data. Writing to a block is done by reading the old data, making the needed modifications, and then writing the modified data to a new physical block, which is then mapped to the original LBA. The old block is scheduled for future erasure, which will be done when the controller gets around to it. The repeated overwrites by shred consume the drive's lifetime write cycles for no benefit.

1 members found this post helpful.

I think "fstrim" is what you're looking for. Delete the file, then issue "fstrim [mountpoint]" to discard unused blocks. Note: may not work with some SSD controllers, particularly ones that masquerade as /dev/sdX. But if your device is mounted as /dev/mmcblkN, you can probably use fstrim. An unsupported controller is not expected to cause data loss.

Note that fstrim does not guarantee that the data will ever be actually erased. The "erase blocks" in an SSD are quite large, perhaps 256KB or more. That block will not be scheduled for erasure until the whole thing can be erased. Data from some small file you are trying to eliminate can stick around for a long time.

Just to be pedantic, it's not totally pointless. It's better than nothing because most of your data will be shredded, but never all of it, agreed.