Pardon my ignorance of SSDs and how they work, but aren't seek times supposed to be low or negligible? Isn't a log-structured FS optimised for a disk with high seek time?
I guess my questions boil down to:
1. Why is this approach fast on an SSD? Wouldn't the performance boost be more noticeable on a spinning disk?
2. Shouldn't someone try to make an FS optimised for SSD characteristics? Have someone already done this?
Isn't a log-structured FS optimised for a disk with high seek time?
Sort of. It makes writes sequential (and thus fast) and reads nearly random (and thus slow).
Why is this approach fast on an SSD? Wouldn't the performance boost be more noticeable on a spinning disk?
Old, crappy SSDs have very slow random writes (which is like seeking), so log structuring increases write performance by orders of magnitude. Since random and sequential reads are equally fast on SSDs, the randomized layout doesn't hurt read performance as it does on disks.
Shouldn't someone try to make an FS optimised for SSD characteristics?
If the characteristics are different for every SSD model, no. Recent SSDs are becoming insensitive to access pattern, so the correct "optimization" is probably to perform no optimizations other than trim.
I suspect, without being certain, that recent SSDs are doing this by implementing something like a log-structured filesystem in a translation layer. I also suspect that this is something that's better done in your OS kernel than in your SSD controller, because it has better information to work with.
The correct optimization would be one to minimize wearing out the disk. Essentially, something that would move hot data out from blocks that are in danger of being worn out.
I guess my questions boil down to:
1. Why is this approach fast on an SSD? Wouldn't the performance boost be more noticeable on a spinning disk?
2. Shouldn't someone try to make an FS optimised for SSD characteristics? Have someone already done this?