Have you looked into blkdiscard? It is like fstrim, but it works on entire block devices. NOTE: technically this doesn't promise to wipe the contents, only mark all of the blocks as not caring about the contents. Some SSDs promise that subsequent reads will return all zeros, some do so only lazily (that is, ordering/scheduling of the effect vs read is not guaranteed), some may make no such guarantee at all. It remains the least effort way to prep an SSD for reformatting while producing the least number of writes. As to hdparm, secure erase and the enhanced version aren't supported by all drives (there are ways to check, read the man page). I believe the enhanced version is supposed to clear/reset an encryption key, effectively scrambling the previous contents. I don't recall if this guarantees the disc will show all zeros or no. Probably is, as with discard, implementation defined. Sent from myPhone.
On May 19, 2021, at 3:43 AM, -pj <pj.world@gmx.com> wrote:
On 5/18/21 12:54 PM, Carlos E. R. wrote:
On 18/05/2021 17.55, L A Walsh wrote: On 2021/05/16 18:57, -pj wrote: ...
I am wondering now about USB flash drive devices.
2. Does the use of "dd" on USB flash drives kill the limited lives on these devices in a similar manner also?
???!!... Depends on what you do with "dd". Why would you need or want to use 'dd' unless you want to transfer a disk image. Usually you want to xfer files so 'dd' wouldn't even come into the picture.
3. Does the use of "dd" on a mechanical drive have less of a negative lifespan effect than that of it's effects on SSD or USB devices?
Um...less of a negative effect? Well, since magnetic media isn't known to be very degraded by multiple r/w ops, it would probably generate less wear. But if you use 'dd' to copy a boot-disk-img which you want to use on a flash-drive, 'dd' could be less harmful, than formatting the flash drive, then copying all the files from some mounted source to the target media. Provided the transfer size is bigger than the actual chunk size of the flash media. I never remember what it is? Suppose it is 16K. If you use the default size used by dd which is 512, it would write to the same chunk 16K/512 times.
I think the optimal size would be a multiple of that chunk size.
I would like to thank you all for the excellent suggestions, links and foresight into this topic. I have been unable to respond sooner... I have now been able to put together notes with Kate text editor piecing/documenting links and thoughts about this. One particular comment (without me looking into the links on this "file" which has now been created) the following seems extremely interesting:
hdparm can do it.
--security-erase PWD Erase (locked) drive, using password PWD (DANGEROUS). Password is given as an ASCII string and is padded with NULs to reach 32 bytes. Use the special password NULL to represent an empty password. The applicable drive password is selected with the --user-master switch (default is "user" password). No other options are permitted on the command line with this one.
--security-erase-enhanced PWD Enhanced erase (locked) drive, using password PWD (DANGEROUS). Password is given as an ASCII string and is padded with NULs to reach 32 bytes. The applicable drive password is selected with the --user-master switch (default is "user" password). No other options are permitted on the command line with this one.
I have heard of this "hdparm" program before and never looked into it more deeply. So basically now I have alot of leads here.
Please feel free to suggest or leave your thoughts if anything more comes to mind. 😁
--Wishes