Re: Summary: Moving /tmp to tmpfs makes it useless
Henrique de Moraes Holschuh <hmh@debian.org> writes:
> On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
>> Henrique de Moraes Holschuh <hmh@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
Reply to: