Best practices for SSD

[Wade Hampton]

Is there a current best practices for use of solid state disks with
Fedora 20?  I found an older doc for Fedora 14 and also the Red Hat 6
deployment guide, but both don't have a lot of details.

I have a laptop and am installing a 120G SSD.  Also I plan on
updating an old CentOS server with a single 120G SSD (CentOS 5.10).

Some of the recommendations I have found:

- partition on a 1M boundary
- use native partitions, not LVM (for TRIM)
- mount using relatime (or noatime for CentOS 5)
- mount using discard (or use the fstrim program periodically)
- use EXT4

Other recommendations I have seen recommended:
- move some temporary files to tempfs
- move /tmp to RAM:  /etc/fstab
       tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
- change I/O scheduler by adding "elevator=noop" to boot parms
- reduce swappiness:  /etc/sysctl.conf
      vm.swappiness=1
      vm.vfs_cache_pressure=50

Thanks,
--
Wade Hampton

[Matthew Miller]

On Thu, Feb 06, 2014 at 09:43:40AM -0500, Wade Hampton wrote:
>  Some of the recommendations I have found: 
I know about some of these and not others without research, so I'll just
answer those parts.

>  - use native partitions, not LVM (for TRIM) 
TRIM should work on LVM now.

>  - mount using relatime (or noatime for CentOS 5) 
This is the default.

>  - move /tmp to RAM:  /etc/fstab
>         tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 
This is the default.


-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

[John Horne]

On Thu, 2014-02-06 at 09:43 -0500, Wade Hampton wrote:

>  - change I/O scheduler by adding "elevator=noop" to boot
> parms
>  
No longer needed it seems.

>  - reduce swappiness:  /etc/sysctl.conf 
>        vm.swappiness=1
>        vm.vfs_cache_pressure=50
>  
Yes, I do this for my SSD. I put them into a file in '/etc/sysctl.d'.

I use my SSD for root (/), but for things that change frequently
(e.g. /home, /var) I use an internal hard drive.

Take a look for some tips:
https://wiki.archlinux.org/index.php/Solid_State_Drives





John.

-- 
----------------------------------------------------
John Horne                   Tel: [phone]
Plymouth University, UK      Fax: [phone]

[Chris Murphy]

On Feb 6, 2014, at 7:43 AM, Wade Hampton <wadehamptoniv(a)gmail.com&gt; wrote:

>  - partition on a 1M boundary 
Has been this way by default for some time.

>  - use native partitions, not LVM (for TRIM) 
Well this wouldn't be a reason to not use LVM, I'd come up with something else,
like it's a PITA to do what it suggests is easy like resizing. For a single drive, I
see no point.

>  - mount using relatime (or noatime for CentOS 5) 
This is the default for ext4, XFS, and Btrfs anyway.

>  - mount using discard (or use the fstrim program periodically)
The discard/TRIM debate can be found in the archives and also on devel@ archives, and on
XFS archives. Not all SSDs perform that well with discard mount option because TRIM is a
non-queued command, therefore for TRIM commands to be issued the drive cache must be
cleared of all other commands and this can actually make things slower. So really it
depends on your workload type, and the SSD you're using. I wouldn't assume you
must have this enabled. Pretty much every source on this has been wrong, notable the crap
resulting from coverage of Ubuntu moving to discard by default.

>  - use EXT4 
Why? You can use ext4, XFS or Btrfs. If anything the reverse order of that is how much fs
dev emphasis on ssd optimization there's been.


>  Other recommendations I have seen recommended:
>  - move some temporary files to tempfs 
>  - move /tmp to RAM:  /etc/fstab 
This is the default since Fedora 18.

>  - change I/O scheduler by adding "elevator=noop" to boot
> parms 
It's an open debate on whether deadline or noop is better for SSDs. It depends on the
workload. Either is probably better than CFQ which is still the default for 3.14 kernels
in koji. It's not like CFQ is hideous or anything. You're unlikely to notice a
difference unless you're doing a lot of reads and write, or parallel tasks to multiple
drives. I'm currently using deadline with Btrfs and SSD.

Add it to /etc/default/grub in GRUB_CMDLINE_LINUX= and then
grub2-mkconfig -o /boot/grub2/grub.cfg      # on BIOS
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg  # on UEFI



>  - reduce swappiness:  /etc/sysctl.conf 
>        vm.swappiness=1
>        vm.vfs_cache_pressure=50 
I wouldn't do this. If swap is needed, then swap is needed. If you don't like
that, get more RAM. If you're nervous about the SSD being worn due to swap, then
again, get more RAM. Conversely, you're unlikely to put that much wear on it with
normal swap usage.

A cute trick I read on the XFS list some weeks back was using an SSD with a large pile of
swap so that a system with limited RAM was able to do an xfs_repair on a massive file
system in much less time than without swap. xfs_repair needs gobs of RAM, but it will use
less and you'll just have to wait a whole lot (incredibly) longer. So if it's
being used for that instead of getting more RAM, I think you're fine with defaults.


Chris Murphy

[Heinz Diehl]

On 09.02.2014, Chris Murphy wrote: 

>  > - reduce swappiness:  /etc/sysctl.conf 
>  >       vm.swappiness=1
>  >       vm.vfs_cache_pressure=50 
>  I wouldn't do this. If swap is needed, then swap is needed.
While vfs_cache_pressure = 50 is the standard, swappiness set to 1
does not mean that the kernel won't swap. In fact, it even swaps when
set to 0. It's a matter of taste and use if you want to get rid of 
unused pages in your memory faster or not.

[Chris Murphy]

On Feb 8, 2014, at 3:04 PM, Michael Cronenworth <mike(a)cchtml.com&gt; wrote:

>  On 02/07/2014 06:54 PM, Chris Murphy wrote:
> > And here is a recent thread, just under one year old….
> > 
> > https://lkml.org/lkml/2013/2/23/107
> > 
> > Anyway, the fs developers have been speaking about it quite a bit and for a long
> time.
>  
>  I guess I could have Google'd for this, but after reading over a few of these links
> they don't produce any quantitative evidence that TRIM (in its current state) causes a
> significant problem. 
So what you really wanted was quantitative evidence, rather than reading what fs
developers had to say about using trim. In that very thread, the O.P.s problem was solved
by removing the discard mount option. I don't understand how that's not
qualitative evidence, or how the described problem wasn't significant.

There are all sorts of threads where users are having brief system hangs, to outright
sluggishness, and they go away when trim is disabled.

And even aside from what you might consider minor performance hiccups, how about it being
totally disqualifying for use in raid of any sort if trimmed sectors return
non-deterministic results when subsequently read?


>  I see theoretical discussions that TRIM, being non-queued, can be
> detrimental. However, real-life performance tests show TRIM use to be insignificant.
It clearly depends a lot on the SSD used and workload involved. That sata-io have
published SATA Rev.3.1 with a queued trim command expressly to address the problems that
occur when mixing queued and non-queued commands in typical usage seems fairly significant
to me. The storage manufacturers agree with each other almost as a last resort, and rarely
so quickly.

>  
>  Windows 7 and higher uses TRIM in a "discard"-like manner and it is
> automatically enabled. I do not hear of Windows users complaining about poor performance
> or blog posts recommending it be disabled (in fact Google will show the opposite). 

I supposed you've Googled this with the same thoroughness as before?

As it turns out there's quite a trove of results for people having short freezes in
Windows attributed to SSDs. Once they learn how to disable trim for the drive, their
problems go away. It's also misleading to say that Windows always enables trim,
because at least if the drive isn't also supporting drat and dzat it won't enable
it. And not all drives do support some form of deterministic read after trim.

I'd characterize the problem as a minority case, but it seems in the vicinity of a
significant minority, if you have certain cheap/crap SSDs on the market and a workload
that triggers the problem. But it's not like it's rare, and it's not like
it's a figment of people's imagination. Like I mentioned before, Apple doesn't
enable it on any 3rd party drives by default, and it's not because they can't.
It's likely because of the way they're constantly creating and deleting small
files (mostly application preferences and system configuration files) in order to get
something like what COW file system would get them for free, they create a new file, and
delete the old on rather than overwriting it. When I had trim enabled in OS X with my none
crappy or cheap Samsung 830, I noticed an occasional 3-5 second freeze where the system
wasn't responsible. After disabling trim the problem went away. With or without the
discard option with Btrfs on the same system, I've thus far experienced no difference
in behavior, but then Btrfs is COW and likely has substantially better delayed allocation
and batch trimming than what Apple is doing.

But yes that's all rather anecdotal than either qualitative or quantitative.

Chris Murphy

[Michael Cronenworth]

On 02/07/2014 06:54 PM, Chris Murphy wrote:
>  And here is a recent thread, just under one year old….
>
>  https://lkml.org/lkml/2013/2/23/107
>
>  Anyway, the fs developers have been speaking about it quite a bit and for a long time.
I guess I could have Google'd for this, but after reading over a few of these 
links they don't produce any quantitative evidence that TRIM (in its current 
state) causes a significant problem. I see theoretical discussions that TRIM, 
being non-queued, can be detrimental. However, real-life performance tests show 
TRIM use to be insignificant.

Windows 7 and higher uses TRIM in a "discard"-like manner and it is 
automatically enabled. I do not hear of Windows users complaining about poor 
performance or blog posts recommending it be disabled (in fact Google will show 
the opposite).

[Chris Murphy]

On Feb 7, 2014, at 2:00 AM, sam tygier <samtygier(a)yahoo.co.uk&gt; wrote:

>  On 06/02/14 23:35, Chris Murphy wrote:
> > On Feb 6, 2014, at 7:43 AM, Wade Hampton <wadehamptoniv(a)gmail.com&gt; wrote:
> >> - mount using discard (or use the fstrim program periodically)
> > 
> > The discard/TRIM debate can be found in the archives and also on devel@ archives, and
> on XFS archives. Not all SSDs perform that well with discard mount option because TRIM is
> a non-queued command, therefore for TRIM commands to be issued the drive cache must be
> cleared of all other commands and this can actually make things slower. So really it
> depends on your workload type, and the SSD you're using. I wouldn't assume you
> must have this enabled. Pretty much every source on this has been wrong, notable the crap
> resulting from coverage of Ubuntu moving to discard by default.
> > 
>  
>  Ubuntu will be using a cronjob that calls fstrim, not the discard mount option. They
> found that the discard option cause a small performance hit. 
Oops, that's right, thanks for the correction. I think they've gone with the
better generic option using fstrim instead of discard: better in that it'll eventually
get the SSD information on what blocks are no longer used by the file system, but also
won't hang up certain SSDs that perform non-queued TRIM function slowly.

Chris Murphy

[Michael Cronenworth]

On 02/07/2014 03:00 AM, sam tygier wrote:
>  Ubuntu will be using a cronjob that calls fstrim, not the discard mount option.
>  They found that the discard option cause a small performance hit.
>  https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming 
If you read the link you posted you will find that their discard testing is 
inconclusive. They only tested 2 SSDs.

The whole discard vs. fstrim debate is entirely speculation. I haven't seen any 
fs maintainer speak up on either side either. The debate has been limited to 
blog posters and vocal end-users with their opinions.

[Chris Murphy]

On Feb 7, 2014, at 5:44 PM, Chris Murphy <lists(a)colorremedies.com&gt; wrote:

>  
>  On Feb 7, 2014, at 5:11 PM, Michael Cronenworth <mike(a)cchtml.com&gt; wrote:
>  
> > On 02/07/2014 03:00 AM, sam tygier wrote:
> >> 
> >> Ubuntu will be using a cronjob that calls fstrim, not the discard mount option.
> >> They found that the discard option cause a small performance hit.
> >> https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming
> > 
> > If you read the link you posted you will find that their discard testing is
> inconclusive. They only tested 2 SSDs.
> > 
> > The whole discard vs. fstrim debate is entirely speculation. I haven't seen any
> fs maintainer speak up on either side either. The debate has been limited to blog posters
> and vocal end-users with their opinions.
>  
>  Well it's an old topic for them, you have to go back 3+ years, which is maybe not
> what you expect when only in the last few months some loud mouths on /. and Engadget
> shriek ZOMG Linux just now is getting TRIM?! And how basic this is on Windows and OS X
> (despite OS X only enabling trim for Apple branded SSDs).
>  
>  
>  Theodore T'so has spoken up on the ext4 list, as have others:
>  http://www.spinics.net/lists/linux-ext4/msg13071.html
>  
>  Dave Chinner has said some things about it on the XFS list, as have others:
>  http://oss.sgi.com/archives/xfs/2013-07/msg00922.html
>  
>  http://oss.sgi.com/archives/xfs/2011-05/msg00338.html
>  
>  And there's a pile of discard/trim conversations on LKML, LVM, Btrfs, on and on.

And here is a recent thread, just under one year old….

https://lkml.org/lkml/2013/2/23/107

Anyway, the fs developers have been speaking about it quite a bit and for a long time.

Chris Murphy

[Chris Murphy]

On Feb 7, 2014, at 5:11 PM, Michael Cronenworth <mike(a)cchtml.com&gt; wrote:

>  On 02/07/2014 03:00 AM, sam tygier wrote:
> > 
> > Ubuntu will be using a cronjob that calls fstrim, not the discard mount option.
> > They found that the discard option cause a small performance hit.
> > https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming
>  
>  If you read the link you posted you will find that their discard testing is inconclusive.
> They only tested 2 SSDs.
>  
>  The whole discard vs. fstrim debate is entirely speculation. I haven't seen any fs
> maintainer speak up on either side either. The debate has been limited to blog posters and
> vocal end-users with their opinions. 
Well it's an old topic for them, you have to go back 3+ years, which is maybe not what
you expect when only in the last few months some loud mouths on /. and Engadget shriek
ZOMG Linux just now is getting TRIM?! And how basic this is on Windows and OS X (despite
OS X only enabling trim for Apple branded SSDs).


Theodore T'so has spoken up on the ext4 list, as have others:
http://www.spinics.net/lists/linux-ext4/msg13071.html

Dave Chinner has said some things about it on the XFS list, as have others:
http://oss.sgi.com/archives/xfs/2013-07/msg00922.html

http://oss.sgi.com/archives/xfs/2011-05/msg00338.html

And there's a pile of discard/trim conversations on LKML, LVM, Btrfs, on and on.


Chris Murphy

[sam tygier]

On 06/02/14 23:35, Chris Murphy wrote:
>  On Feb 6, 2014, at 7:43 AM, Wade Hampton
> <wadehamptoniv(a)gmail.com&gt; wrote:
> > - mount using discard (or use the fstrim program periodically)
>
>  The discard/TRIM debate can be found in the archives and also on devel@ archives, and on
> XFS archives. Not all SSDs perform that well with discard mount option because TRIM is a
> non-queued command, therefore for TRIM commands to be issued the drive cache must be
> cleared of all other commands and this can actually make things slower. So really it
> depends on your workload type, and the SSD you're using. I wouldn't assume you
> must have this enabled. Pretty much every source on this has been wrong, notable the crap
> resulting from coverage of Ubuntu moving to discard by default.
>  
Ubuntu will be using a cronjob that calls fstrim, not the discard mount option. They found
that the discard option cause a small performance hit.
https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming

Sam