Revisions to Is shred bad for erasing SSDs?

(Suggested edit: 'No need to use "sane' to mean "good"') Fair enough, I really meant legal/accepted/valid anyway. So I should just say that.

Source Link

edited Nov 21, 2021 at 7:09

FeRD

990
6
21

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(8) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a sensiblevalid/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(8) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a sensible/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(8) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a valid/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

No need to use "sane' to mean "good", plenty of good things are insane ☺ https://en.wikipedia.org/wiki/Sanism

Source Link

edit approved Nov 21, 2021 at 7:09

3wordchant

138
5

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(8) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a sanesensible/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(8) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a sane/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(8) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a sensible/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

Unsurprisingly, blkdiscard is in manual section 8. Duh.

Source Link

edited Jun 18, 2020 at 10:53

FeRD

990
6
21

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(18) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a sane/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(1) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a sane/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(8) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a sane/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

Source Link

answered Jun 17, 2020 at 16:46

FeRD

990
6
21

Loading

Stack Exchange Network

Return to Answer