On Mon, Apr 13, 2020 at 7:55 AM Michael <confabul...@kintzios.com> wrote: > > I have noticed when prolonged fstrim takes place on an old SSD drive of mine > it becomes unresponsive. As Rich said this is not because data is being > physically deleted, only a flag is switched from 1 to 0 to indicate its > availability for further writes.
That, and it is going about it in a brain-dead manner. A modern drive is basically a filesystem of sorts. It just uses block numbers instead of filenames, but it can be just as complex underneath. And just as with filesystems there are designs that are really lousy and designs that are really good. And since nobody sees the source code or pays much attention to the hidden implementation details, it is often not designed with your requirements in mind. I suspect a lot of SSDs are using the SSD-equivalent of FAT32 to manage their block remapping. Some simple algorithm that gets the job done but which doesn't perform well/etc. This makes me wonder if there would be a benefit from coming up with a flash block layer of some sort that re-implements this stuff properly. We have stuff like f2fs which does this at the filesystem level. However, this might be going too far as this inevitably competes with the filesystem layer on features/etc. Maybe what we need is something more like lvm for flash. It doesn't try to be a filesystem. It just implements block-level storage mapping one block device to a new block device. It might very well implement a log-based storage layer. It would accept TRIM commands and any other related features. It would then have a physical device translation layer. Maybe it would be aware of different drive models and their idiosyncrasies, so on some drives it might just be a NOOP passthrough and on other drives it implements its own log-based storage with batched trims on large contiguous regions, and so on. Since it isn't a full POSIX filesystem it could be much simpler and just focus on the problem it needs to solve - dealing with brain-dead SSD controllers. -- Rich
