Re: Summary: Moving /tmp to tmpfs makes it useless
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...
> 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.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: