Re:SSD: How to Optimize Your Solid State Drive for Linux
by baruch on Sunday May 31, 2015 @05:04AM
(#9633570)
I would argue that preferring to reuse the same space of the SSD instead of using new space as you propose (cow, et al.) is the better approach. This way you don't need to use trim that much and the SSD will anyway write it into a different place.
It should be noted that while an SSD can't write before erasing it will actually not even attempt that. The SSD maintains a mapping from LBA to physical flash chip and offset and will write to a completely different place. It will then mark the old location as unused and erase it when it can spare some time and power.
Re:SSD: How to Optimize Your Solid State Drive for Linux
by rcthompson on Sunday May 31, 2015 @05:10AM
(#9633579)
I'm pretty sure that the SSD performs wear leveling regardless of whether you're overwriting an existing file or creating a new copy. Just because you're logically rewriting the contents of a file doesn't mean the SSD will store the new contents in the same physical location.
Re:SSD: How to Optimize Your Solid State Drive for Linux
by baruch on Sunday May 31, 2015 @05:13AM
(#9633585)
F2FS is for direct NAND access, if you do it over an SSD that already has an FTL (flash translation layer) you'll gain nothing and only cost extra writes.
Re:SSD: How to Optimize Your Solid State Drive for Linux
by ThatPlayer on Sunday May 31, 2015 @05:33AM
(#9633631)
I can't say I'm too familiar with it, but this article says F2FS specifically targets the flash translation layer.
I think a copy-on-write filesystem like btrfs would be better on SSDs because they do not change written data but rather write to a new area on the drive, requiring less erases on the SSD's side.
There's also F2FS (Flash-Friendly File System) which has been in the Linux kernel for a while now that specifically targets flash based drives.
Though I agree that most of these optimizations do not seem necessary on modern SSDs.
[0] https://github.com/graysky2/profile-sync-daemon