SSD Trim support

[vox]

... would enable full range of SSDs to be used with no worries

Its not high level thing, but would be nice

"Hard drive is dead, long live SSD"

[kicko]

Im not so good in all the details about TRIM but what would that give us if supported ? Just curious

[vox]

[quote="kicko"]Im not so good in all the details about TRIM but what would that give us if supported ? Just curious[/quote

Reliability of use of SSDs that are cheaper.

http://www.apartmenttherapy.com/trim-th ... tte-142681

At this time its recommended to buy those who trim themselves.

http://forums.crucial.com/t5/Solid-Stat ... a-p/100276
http://en.wikipedia.org/wiki/Garbage_co ... collection
http://www.thessdreview.com/daily-news/ ... sd-primer/

[thomasrapp]

I don't see how TRIM can increase the reliability of an SSD. It only prevents the reduction of write speed when all cells of the SSD have been written to at least once. So it's about performance, not about reliability.

Self-TRIMimg SSDs don't exit. It's illogical, it cannot exist. An SSD (like every hard drive) is a mass storage device which presents itself to the SATA bus as a long series of blocks without any other structure. The OS has a driver which presents the same series of blocks to the DOS. The DOS divides the series of blocks into smaller series of blocks called partitions and mounts a file system on each partition. Only the file system knows which blocks are occupied on a partition and which aren't. Therefore the file system is the only part which can form TRIM commands and send them to the driver which forwards them to the SSD.

A very intelligent SSD firmware could perhaps know about the MBR/GPT partition scheme and FAT/NTFS file systems so that it can TRIM automatically. Perhaps even EXT2/3. But surely not FFS or SFS, not to mention the RDB partition table scheme.

I think that "garbage collection" mentioned in one of your links is something different. It probably looks for blocks which are filled with all the same value. For example a block which is filled with all zeroes can be marked as filled with zeroes and TRIMed. But this is different from true TRIM commands. I am quite sure that Amiga file systems don't fill deleted files with zeroes, so deleted files will never be TRIMed as they should.


For the Amiga without true TRIM support, using an SSD means that once write speed decreases, you either have to live with it or you have to make a complete backup, connect the SSD to a PC, use a manufacturer's tool to clean it completely and then connect it back to the Amiga, repartition it and restore the backup.

[ssolie]

I don't see any point in spending effort on an outgoing feature. I think all future drives will take care of this (as they always should have) themselves.

[chris]

I don't see any point in spending effort on an outgoing feature. I think all future drives will take care of this (as they always should have) themselves.

I doubt it. How does the drive know which blocks are in use by the filesystem? It needs the fs to tell it which blocks it can reclaim. If you delete a file the fs removes it from the directory mapping, but as far as the SSD is concerned the data is still present, so it won't be able to use those blocks for wear-levelling. If the drive gets full it will then struggle with space for wear-levelling and the flash cells will die quickly.

You could leave a lot of the drive unpartitioned, or buy an expensive drive that does static wear-levelling, but neither of these things really solves the problem.

[vox]

I don't see any point in spending effort on an outgoing feature. I think all future drives will take care of this (as they always should have) themselves.

Tell it to someone that buys SSD with no auto garbage collector and sees it dead because there is no trim under AmigaOS.
You should see the faces of IT salesmen when I ask for this SAFETY FEATURE. In the end, one finds the needed hardware
on the web

However, yes there are more pressing matters now. But it doesn`t make this one irrelevant.