Henrique de Moraes Holschuh <h...@debian.org> writes: > On Sun, 24 Jun 2012, Goswin von Brederlow wrote: >> Henrique de Moraes Holschuh <h...@debian.org> writes: >> > I've read that some SSDs really *dislike* the way Linux does TRIM >> > batching (or doesn't :p), so yes, it may well be that on most SSDs >> > regular fstrim will do much better. >> >> I'm assuming this is due to fragmentation. With TRIM you get lots of >> small free chunks. With fstrim you get huge batches. > > AFAIK, it is related to trim requests not being of the same type as > write/read requests (so you have to drain the queue of all in-flight > commands or something), some SSDs being allergic to large batched trim > requests while others are allergic to unbatched small trim requests, > übershitty implementation of said command in SSDs (high latency, > synchronous), etc. On top of whatever performance issues the Linux support > for TRIM at the storage stack and filesystems might have. > > It may well have no fix. fstrim is not performance sensitive (people will > run it when they have the time to wait for it to complete), so it doesn't > matter if the SSD is very bad at TRIM and goes out for lunch for several > seconds per trim request...
Ahh, that makes more sense. I thought you ment normal read/write (without interleaved TRIM) would become slower. >> But if the disk doesn't defrag then won't it just be a matter of time >> for it to get slow with fstrim too? > > Any SSD worth its price has both the reserved flash and the background > garbage collection systems required to defrag itself if left idle for long > enough. But regular TRIMming lets it do a much better job. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hatz1z5c.fsf@frosties.localnet