3 ms·
> The way TRIM works, you don't need to trim blocks right before overwriting them. In my experience "blkdiscard /dev/DESTINATION_DISK" does improve the speed o
by eMGm4D0zgUAVXc7 7y ago
> The way TRIM works, you don't need to trim blocks right before overwriting them.
In my experience "blkdiscard /dev/DESTINATION_DISK" does improve the speed of dd'ing a disk to another one quite a bit though.
And that does make some sense IMHO:
If the SSD's internal datastructure which keeps track of pages which hold user-data is empty then each write will consume less time for looking up if the specific sector is contained in the datastructure.
- wtallis 7y ago> then each write will consume less time for looking up if the specific sector is contained in the datastructure. For most SSDs, this lookup is a single DRAM fetch per 4kB of user data, and therefore much faster than even a single NAND flash read, let alone a NAND flash program or erase operation. The reason that imaging a SSD is faster after it's been trimmed or secure erased is that every erase block is empty and ready to accept new data. When you overwrite data on a used disk, the drive has to free up erase blocks and that generally involves moving old data elsewhere to preserve it—because the drive doesn't know that the commands to overwrite that are also coming soon.
- nybble41 7y agoIt also avoids wasting time (and write endurance) shuffling around data which is just going to be overwritten anyway. That could happen either as a result of static wear leveling or just because the drive needed to erase a block with a mix of valid and overwritten pages to make room for new data.