Most SSD performance issues are hidden behind years of SSD performance optimization tricks involving caches, code, and cleverness. However, at the end of the day, if you understand what is supposed to be going on, you can usually design a pathological case that hits it where it hurts. When worrying about the free pool in an SSD, you really need to be aware of all the implementation details, such as what the reserve size is, and then figure out how to flood it with your hypothetical test.
I once had an insipid argument with Jordan when I asked iX to default to undersizing the SLOG partition in order to get better free pool performance under heavy write loads. Jordan asked me to PROVE that this was the case, and I declined, because I've got better things to do than to do someone else's product improvement proofs for them. Apparently they did eventually get around to figuring this out themselves -- after Jordan was gone. But one of the things to remember here is that there is a relationship between theory and physical reality. The theory that ashift=13 reduces wear on 8K devices might be right or wrong, because who knows what implementation details might mess with it, but the physical reality is that not-ashift=13 is going to cause partial writes or garbage collection on 8K devices in some (probably many) cases *guaranteed*.
