On 21/09/18 11:39, Wols Lists wrote: > I've been thinking about adding a TRIM functionality to md-raid, and in > theory it's dead easy. Just track all writes, have a bitmap per sector > or track or whatever to record what's in use, and bob's your uncle. It > just chews up a load more disk space to record that bitmap, adds more > complexity to the code, and needs someone to code it up. And as always, > that last requirement is probably the hardest one to fill. This is > exactly the sort of hardening / maintenance coding I would love to do, > but I just can't find the time/hardware to get stuck in. > I would not bother with this. SSD TRIM - especially on SATA - is underpowered and overhyped. As I see it, it was mainly a panic reaction by the industry when they realised the drop in performance in benchmarks of early SSDs when they were nearly full. If you have a half-decent modern SSD - and most people using raid will go for at least half-decent devices - the overprovisioning and automatic garbage collection and write levelling mean that you usually have plenty of free blocks. And since you typically need to be running continuous writes at absurd speeds to wear out the disks, the unnecessary extra writes from copying trimable data is rarely relevant. Where TRIM would be useful in the context of raid is in tracking which parts of the array need to be synchronised. I haven't been following kernel raid progress much recently, so I don't know the current state - but if tracking TRIM (especially batch trims, with fstrim) at the raid level means you could ignore syncs on unneeded disk data, then you'd have a very useful feature.
