On Mon, Mar 10, 2014 at 6:05 PM, Thomas Taylor
Are SSDs (solid state drives) well supported in factory versions? Anybody have any hints or gotchas?
Thanks, Tom
The recommendations about using discard did not provide any background to let you make the right choice. Here's some background info that should help: ============ openSSUE has been ready for SSDs since 11.4, so no features from factory are needed. This background wiki page is mostly from 2010. It would be great if knowledgeable people would update it, as it has gotten a little out of date: https://en.opensuse.org/SDB:SSD_discard_(trim)_support To the best of my knowledge it is still a good SSD "trim" primer, so please take a minute to read it and understand the trim technology. Note that it says "As of 11.4, fstrim is part of the linux-util package and is the recommended choice for invoking trim for most users." The incorporation of fstrim into 11.4 was the point I claim opensuse was fully SSD ready. Also note that it is not stated on that page, but "trim" is an ignorable command by the SSD. if it chooses for whatever reason, it can ignore trim commans. Thus trim is a highly unreliable command. == ext4 only below, because I don't know the facts for XFS or BTRFS == realtime discards issued by ext4 when files are deleted may be a performance boost for some drives, but it does not mean you should not also schedule batched discards on a regular basis. fstrim in particular will walk an ext4 filesystem and send out a trim command for all unallocated blocks in the filesystem. Calling fstrim nightly will ensure any ignored trims eventually get acted on by the SSD. As a user you have two choices with ext4, add a discharge arg to mount (via fstab) which will cause realtime trims. And/or call fstrim via cron on a regular basis. It is only in the last year or so that "trim" is an asynchronous / queue-able command to some drives. For all others, it is a synchronous, non-queue-able command. For the majority of the installed SSDs, that means it is synchronous. I don't know how to tell which way a given drive handles trim commands, so I would default assume any drive I was installing was synchronous. For SSDs that implement trim as a synchronous command: - realtime discards by the filesystem driver mean every trim command causes a cache flush on the drive itself. This has proven to mean a loss of performance, not a gain. Thus for the majority of SSDs batched discard via fstrim is highly preferred as it is schedulable event and only takes 30 seconds or so to complete in most circumstances. For SSDs that implement trim as a asynchronous command: - This means the drives have finally reached the maturity level assumed by the kernel filesystem devs 5 years ago when they wrote the ext4 realtime discard support. That means if you are lucky enough to own one of these drives, you can finally use the discard mount option without a loss of performance. I haven't seen any benchmarks of using discard as a mount option vs. calling fstrim routinely (eg. daily). For me, I would continue to use fstrim since it is a well tested and known commodity and I've yet to see a benchmark saying realtime discards improve performance over nightly fstrim calls. If I did decide to use the "discard" feature of ext4, I would still use a cron entry to call fstrim on a regualr bases (eg. daily) === Once you resolve the "trim" issue, this wiki page has a bunch of additional good info on it about other performance issues. http://en.opensuse.org/SDB:SSD_performance This page was mostly written in 2011 and the first one was from 2010 era. Neither make reference to the newer SSDs that implement trim as an asynchronous command, so neither recommend the use of the realtime trims. Also I don't think either talks about trim as an unreliable command. Again, it would be nice if someone would udate them to talk about some of what I wrote above. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org