Mailinglist Archive: opensuse-factory (439 mails)

< Previous Next >
Re: [opensuse-factory] Adding SSDs?
  • From: Jason <relentropy@xxxxxxxxx>
  • Date: Tue, 11 Mar 2014 21:11:24 +0800
  • Message-id: <14998290.krJAGXrNp7@host.laptop>
On Tuesday, March 11, 2014 08:39:05 Greg Freemyer wrote:
On Mon, Mar 10, 2014 at 6:05 PM, Thomas Taylor <tommyttt5@xxxxxxxxxxx>
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

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

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.

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

Again, it would be nice if someone would udate them to talk about some
of what I wrote above.

Hey, not the OP, but thanks for the info!

AFAIK btrfs has SSD mode but that only applies to how it writes the data,
fstrim is still applicable though I wouldn't recommend it for daily chron.
Weekly should suffice if you're not running hp databases off of it.

Someone feel free to correct me:P

tangentially related, during 12.3 installation I couldn't format / as btrfs so
I went with ext4. I know of the tool btrfs-covert, but is it applicable for
root system partition?
Or if someone has some input on how to do it without

Kind regards,
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups