Mailinglist Archive: opensuse-kernel (87 mails)

< Previous Next >
Re: [opensuse-kernel] SSD / filesystem / TRIM
  • From: Greg Freemyer <greg.freemyer@xxxxxxxxx>
  • Date: Mon, 30 Aug 2010 15:04:07 -0400
  • Message-id: <AANLkTimkM9CugsLHyNiNf+4wJWmvAWvYKYR12WGE61RQ@xxxxxxxxxxxxxx>
On Mon, Aug 30, 2010 at 5:39 AM, C <smaug42@xxxxxxxxx> wrote:
On Mon, Aug 30, 2010 at 11:26, Thomas Hertweck wrote:
On 30/08/10 07:29, Takashi Iwai wrote:
At Sun, 29 Aug 2010 11:41:17 -0700,
Greg KH wrote:
Not at all.  Just plug it in and use it like a "normal" disk and all
will work just fine, that's what I do.  Nothing special at all and it
works _way_ faster than a "normal" disk.

Yes, there seem some misunderstanding.  Normal users don't need
anything.  SSD works just as is, and it's fast enough.

If you are adventurous, you can go quest for the performance
optimization with TRIM support.  But normal people don't need it at
this moment.  So, arguing about the usability for normal users doesn't
make sense for now.

Thanks for the reassurance. Everybody on the internet seems to be talking
about TRIM etc when it comes to SSD, that's why it looks to be so
important (even the openSUSE wiki focuses on TRIM). Without having the
proper technical background in ATA, filesystem, and SSD technology, it's
difficult to know who's right and who's wrong. Anyway, the SSD works fine

You're not the only one struggling with this... there's two camps...
those that say don't worry, it just works and you see major speed
increase, and those who say no no no, trim is crucial, and there are
no significant performance differences anyway.  Two polar opposite
camps with convincing arguments on both sides.

I'm interested in your test results.  I really would like to try it
out too... I'm considering installing root and /home on an SSD and use
regular drives for long term storage for things like static media
files and documents that are not accessed every day.


Getting trim support working with SSDs is like giving a race car a
final pre-race tune-up. Its a smart thing to do and worth the effort,
but a race car is fast even if not perfectly in tune.

In my opinion the Windows kernel and Linux kernel trim implementations
both offer only marginal performance improvement over standard ATA-7
like SSD performance because they don't leverage the fact a TRIM
command can accept multiple trim ranges in the payload.

(Red Hat has done benchmarks in which they don't show much advantage
from the ext4 --discard option at all. They even submitted a patch to
remove the option. The patch was rejected because hardware may
eventually exist that works well with the current implementation. It
caused a big thread on the ext4 mailing list.)

Rad Hat now has proposed a new fitrim() ioctl, but its not performance
is not too much better than whats in the 2.6.35 (and older) kernels.
The block layer needs to grow a new API in my opinion to handle a
discard range vector, not just discrete discard ranges. Who knows
maybe 2.6.37 will get that.)

For now in Linux, only the hdparm / script even attempts to
do that. I saw Thomas failed attempt, so apparently its not fully
working yet either but at least it tries.

To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx

< Previous Next >