On Mon, Aug 30, 2010 at 5:39 AM, C <smaug42@gmail.com> 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.
C.
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 / wiper.sh script even attempts to do that. I saw Thomas failed attempt, so apparently its not fully working yet either but at least it tries. Greg -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org