4 ms·

Anyone know how TRIM works with Linux? I find myself copying entire partitions between SSDs from time to time, is there a utility to clear the destination SSD

Anyone know how TRIM works with Linux? I find myself copying entire partitions between SSDs from time to time, is there a utility to clear the destination SSD before copy? Is it possible to do the same for an SD card, so that writing a new Raspi OS to it doesn't do unnecessary garbage collection?

leetcrew 7y ago
I believe all major OSes support trim in a reasonable way now. afaik it needs hardware support though, so idk how it would work for an SD card.
- cm2187 7y ago
  Unless you have a RAID card in the middle.
  - leetcrew 7y ago
    I don't mean to say it wouldn't work, just that I don't know enough about sd cards to say whether it would/should.
    - cm2187 7y ago
      Sorry, I meant for TRIM being passed down to an SSD.
      - leetcrew 7y ago
        oh gotcha. not sure why I thought it was reasonable to think you were talking about a bunch of SD cards in a raid array...
- monocasa 7y ago
  MMC defines trim as an optional command. But maybe to your point I've generally only seen it implemented on eMMC chips, not SD cards.
zozbot234 7y ago
> I find myself copying entire/ partitions between SSDs from time to time, is there a utility to clear the destination SSD before copy? The way TRIM works, you don't need to trim blocks right before overwriting them. TRIM is for blocks that you aren't going to care about for quite some time, it essentially returns them to the SSD management layer for use as overprovisioning.
- 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 ago
    It 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.
xioxox 7y ago
On linux, it can either get done using fstrim (often run periodically, e.g. via cron), which clears unused blocks, or can be done on file delete on supported file systems (e.g. mounting using the discard option). The periodic trim is supposed to be better, as a SSD does guarantee that a trim returns quickly. If you want to trim an entire device, see blkdiscard (take care!).
- BenjiWiebe 7y ago
  On a systemd based system, you may have fstrim.timer enabled by default. Check: sudo systemctl status fstrim.timer
MertsA 7y ago
If you're trimming an entire device rather than just blkdiscard as mentioned elsewhere you can just issue a secure erase which will restore speed to basically the same as it was out of the box. If you just want to wipe one single partition and not the entire drive then blkdiscard is the best you're going to get.

leetcrew 7y ago

I believe all major OSes support trim in a reasonable way now. afaik it needs hardware support though, so idk how it would work for an SD card.

cm2187 7y ago
Unless you have a RAID card in the middle.
- leetcrew 7y ago
  I don't mean to say it wouldn't work, just that I don't know enough about sd cards to say whether it would/should.
  - cm2187 7y ago
    Sorry, I meant for TRIM being passed down to an SSD.
    - leetcrew 7y ago
      oh gotcha. not sure why I thought it was reasonable to think you were talking about a bunch of SD cards in a raid array...
monocasa 7y ago
MMC defines trim as an optional command. But maybe to your point I've generally only seen it implemented on eMMC chips, not SD cards.

zozbot234 7y ago

> I find myself copying entire/ partitions between SSDs from time to time, is there a utility to clear the destination SSD before copy? The way TRIM works, you don't need to trim blocks right before overwriting them. TRIM is for blocks that you aren't going to care about for quite some time, it essentially returns them to the SSD management layer for use as overprovisioning.

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 ago
  It 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.

xioxox 7y ago

On linux, it can either get done using fstrim (often run periodically, e.g. via cron), which clears unused blocks, or can be done on file delete on supported file systems (e.g. mounting using the discard option). The periodic trim is supposed to be better, as a SSD does guarantee that a trim returns quickly. If you want to trim an entire device, see blkdiscard (take care!).

BenjiWiebe 7y ago
On a systemd based system, you may have fstrim.timer enabled by default. Check: sudo systemctl status fstrim.timer

MertsA 7y ago

If you're trimming an entire device rather than just blkdiscard as mentioned elsewhere you can just issue a secure erase which will restore speed to basically the same as it was out of the box. If you just want to wipe one single partition and not the entire drive then blkdiscard is the best you're going to get.