SSD drives under Linux - discussion thread

[stevea]

UPDATE 3/2/2012
A concise, updated consolidation of this topic appears here.
http://forums.fedoraforum.org/showthread.php?t=277082
You may wish to skip there directly.
---end of update --


I'd like to start a quality thread on how to manage SSD drives under
Linux. (please take the off-topic questions and quips elsewhere)

The basic FAQ questions are answered here:
http://en.wikipedia.org/wiki/Solid-state_drive

I'll skip the "why"s for now, but the practical ways to manage an SSD drive include the following steps:
-----------------------------------------------

1/ File System Alignment:

For performance you should align to at least a multiple of 4KiB (8
sector) boundaries:

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000ac71

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048    63490047    31744000   83  Linux
/dev/sda2        63490048    80283647     8396800   82  Linux swap / Solaris
/dev/sda3        80295936   173000703    46352384   83  Linux

Note: Each start sector is a multiple of 8. Gparted defaults to 1 MiB
boundary alignment (multiples of 2K sectors) which works nicely.

Some sources claim that SSD file system alignment should be on flash erase block
boundaries (often 128KB or 256KB) however manufacturers are almost silent on the
topic, and given the parallel RAID-like organization of recent SSD drives this advise
is questionable. Alignment to 4KiB boundaries makes a clear performance
improvement in many cases.

==

2/ Never use any defragmentation on an SSD file system.
Defragmentation assumes that contiguous read/writes are faster than
non-contiguous, but this is not true on a random access media.
Instead it generated pointless writes which wears the drive.

==

3/ TRIM issues:

TRIM is a method for a computer to notify an SSD drive that certain
blocks are unused and available for reclamation. Using TRIM
dramatically improved write speed as a drive is used. Linux has kernel
support for the TRIM command since 2.6.33 however it has undergone
several substantial revisions. The following notes apply to kernels 2.6.36 and
later.

Does your older SSD drive support TRIM ? There is an easy way to tell:

# su -c 'hdparm -I /dev/sda' | grep TRIM
	   *	Data Set Management TRIM supported
	   *	Deterministic read data after TRIM

The asterisk indicates the feature is available. The first item "TRIM
supported" is the critical one. The second, "Deterministic read" means the
SSD drive will produce a fixed pattern (all zeros or all ones) if you read a block
that is unassigned (never written or in the TRIM free list).

SWAP space on Linux automatically supports TRIM operations when the underlying
drive supports TRIM. No configuration is needed. Early SWAP/TRIM support
(perhaps in 2.6.33 and prior) may cause horrible performance during suspend and
similar use.

The filesystems ext4, gfs2, nilfs2 ,btrfs and vfat all have some support for TRIM.
These filesystems can all be mounted with the "discard" option to allow
released space to be communicated to the drive. The "discard" option can
appear in the "mount -o ." list or in the /etc/fstab file.

The mkfs.ext4 (and ext2, ext3) should be executed without the "-K" option. This
options causes the mkfs.ext4* command to NOT TRIM all the unused blocks of the
file system when it is initially created.

The btrfs mount takes options "ssd" ssd_spread" options. Consult the btrfs wiki
https://btrfs.wiki.kernel.org/ for details.

The hdparm command supports TRIM with the "--trim-sector-ranges" and
"--trim-sector-ranges-stdin" options, however the use of these is considered
hazardous.

Before the 3.6.37 kernel, filesysytems atop a LVM or a software RAID(mdadm) could
not support TRIM. Since 2.6.37 TRIM is supported on filesystems on LVM.and software
RAID can support TRIM.

No It's unclear/doubtful that any file-system atop an LVM block manager
or a RAID block manager can support TRIM at this time.
Therefore you should not use LVM nor RAID (mdadm) atop an SSD for
optimal performance unless you investigate the issue.


The btrfs file system has a "ssd" mount option which does NOT appear
to manage TRIM at this time.

Users frequently ask "What about swap ?". The swap manager does not
manage TRIM at all, however the good news is that no partition,
including swap, will ever allocate more flash than the size of the
partition. So even though an 8GB swap on a a 60GB drive occupies a
considerable fraction of space - if the remaining 52GB is using ext4
or other file system with a well managed TRIM, then the amount of
"unused" space on the ext4 partitions is nearly the same as the amount
of free space that the drive controller recognizes.

If having 8GB (example) permanently allocated from swap is too
annoying, then we could create a script to run at boot time (in
rc.local for example) that would:
1/ remove swap with "swapoff /dev/sdb2"
2/ TRIM the entire swap, for example, (see partitions above)
"hdparm --trim-sector-ranges 63490048:$((80283647+1-63490048))"
Note: this is a very dangerous command
3/ re-create swap, "mkswap /dev/sda2"
4/ remount swap, "swapon /dev/sda2"

==

4/ Remove the elevator disk schedule.

Normally rotating disks use the so-called elevator algorithm to access
blocks. It makes sense with a linear seeking head to seek
continuously from the inner to outer to inner most cylinders. Just as
an an elevator goes from the lowest requested floor, to highest and
then down again. To do this all the pending disk I/O has to be sorted
into cylinder order. This operation makes no sense for a SSD random
access media. Instead add the option "elevator=noop" to the kernel
line in /etc/grub.conf, like:
kernel /boot/vmlinuz.... elevator=noop

This saves a microscopic amount of CPU time preventing the kernel from
sorting disk operations by cylinder. It also may cause operations to
complete more nearly in-order, which can be an advantage.

==

5/ Reduce SSD Write Activity:

A/ mount file systems with the "noatime" option.
"noatime" prevents the file system from updating file access times.
"noatime" includes "nodiratime" (prevents directory access time updates).

B/ Consider whether you need journals.

File system journals make file system reconstruction (fsck for
example) possible, and running without any journal makes catastrophic
file system failure far more likely. On the other hand, journals
require extra write operations, Sometimes it's easy enough to
reconstruct a file system that it's not worth the cost in terms of SSD
write operations. For example I have a procedure to reconstruct the
root file system of any of my several systems in under an hour. I
have a catastrophic file system error rarely (<<1/5yrs). I can afford
to not journal the rootfs of these systems. Further I have a backup
of each /home that is no more that 24 hours stale - so I can afford to
lose each system's /home too. If you don't create reliable and
regular backups - then don't even consider removing the journals.

At a minimum mount each SSD ext4 with the "data=writeback" option.
This means the ext4 will not journal the data (just metadata) and
any fsck will probably succeed, except for the loss of very recently
written data. For the root file system, setting the journal mode
requires adding an option to the kernel line in /boot/grub/grub.conf,
kernel /boot/vmlinuz-2.6..... elevator=noop rootflags=data=writeback
For other non-root SSD file systems we can add the option in /etc/fstab
UUID=24941fe7-6... /home ext4 noatime,discard,data=writeback 1 2

Note: for Linux version 3.0 kernels, setting the ext3/4 root file system option
"data=..." in fstab will prevent the remount and likely to cause boot failure.

For a more aggressive approach one can eliminate journalling
altogether by doing this to a unmounted or read-only ext4
tune2fs -O ^has_journal /dev/sda1
Then there will be no journal. While you are at it the command:
tune2fs -r 1024 /dev/sda1
will reduce the root-reserved blocks to 1k (4MB) which is plenty IMO.

Note that the "commit=nnn" mount option appears to be ignored
since the recent kernel flush daemons were implemented.

C/ Get rid of /tmp
Put it on ramdisk. The X11 server makes a huge number of tiny
writes to /tmp and if these flush to disk at a high rate it creates a
load of writes. Adding this line to /etc/fstab does the trick.

none /tmp tmpfs defaults 0 0


D/ Send logs over the net.
See:
man rsyslog.conf
Also look into logs for Xserver which can become large.

E/ Fix your Firefox to use memory caches.
Some nice notes on configuring firefox to not use disk caches here, set:
browser.cache.disk.enable false
create: (for 64MB of mem cache)
browser.cache.memory.capacity 65536
See:
http://www.ocztechnologyforum.com/fo...mp-Utilities-*

--------------------------------------------------------------------------

A brief buyers note: Study the SSD drive controller carefully before purchasing. The controller has a dramatic impact on performance and also on drive reliability/lifespan.

[DBelton]

==

4/ Remove the elevator disk schedule.

Normally rotating disks use the so-called elevator algorithm to access
blocks. It makes sense with a linear seeking head to seek
continuously from the inner to outer to inner most cylinders. Just as
an an elevator goes from the lowest requested floor, to highest and
then down again. To do this all the pending disk I/O has to be sorted
into cylinder order. This operation makes no sense for a SSD random
access media. Instead add the option "elevator=noop" to the kernel
line in /etc/grub.conf, like:
kernel /boot/vmlinuz.... elevator=noop

This saves a microscopic amount of CPU time preventing the kernel from
sorting disk operations by cylinder. It also may cause operations to
complete more nearly in-order, which can be an advantage.

==

Just a question on this one. What if you have a combination of SSD and regular rotating disks? Would the elevator=noop kernel parameter cause the regular disks to start using the unsorted seek order which would very noticeably drop the performance on those drives?

If it would, then I guess you would then have to weigh which gives you the best overall performance. Increasing it on the SSD and dropping it on the platter drive, or keeping it beneficial to the platter drive at the probably lower drop in performance on the SSD.


Just thought I would throw a wrench in the works here! lol

Great guide you put together, though. Really useful information in here. I haven't really seen this much information on using an SSD in linux all together in one place before.

Thanks for this great information

[roelj]

5/ Reduce SSD Write Activity:

A/ mount file systems with the "noatime" option.
"noatime" prevents the file system from updating file access times.
"noatime" includes "nodiratime" (prevents directory access time updates).

B/ Consider whether you need journals.

File system journals make file system reconstruction (fsck for
example) possible, and running without any journal makes catastrophic
file system failure far more likely. On the other hand, journals
require extra write operations, Sometimes it's easy enough to
reconstruct a file system that it's not worth the cost in terms of SSD
write operations. For example I have a procedure to reconstruct the
root file system of any of my several systems in under an hour. I
have a catastrophic file system error rarely (<<1/5yrs). I can afford
to not journal the rootfs of these systems. Further I have a backup
of each /home that is no more that 24 hours stale - so I can afford to
lose each system's /home too. If you don't create reliable and
regular backups - then don't even consider removing the journals.

At a minimum mount each SSD ext4 with the "data=writeback" option.
This means the ext4 will not journal the data (just metadata) and
any fsck will probably succeed, except for the loss of very recently
written data. For a more aggressive approach one can eliminate
journalling altogether by doing this to a unmounted or read-only ext4
tune2fs -O ^has_journal /dev/sda1
Then there will be no journal. While you are at it the command:
tune2fs -r 1024 /dev/sda1
will reduce the root-reserved blocks to 1k (4MB) which is plenty IMO.

Note that the "commit=nnn" mount option appears to be ignored
since the recent kernel flush daemons wre implemented.

First, thanks for this useful information.
Secondly, how can I do this?

Can I set it somewhere in /etc/fstab?

[DBelton]

yes, you set the noatime in the options in fstab.

like so:

LABEL=Drive\040K /media/Drive_K ext4 defaults,noatime 0 0

However, I have heard of some having problems trying to set data=writeback in /etc/fstab if it's not the default for the drive. It seems that on boot, the filesystem gets mounted read only, then it's remounted read/write. I've heard of some problem with it not being about to change that option on a remount. It may be fixed now, though.

You will probably want to set the journalling options as stevea has shown above.

Edit: I should have said that the problem above would only occur if you were trying to set journalling options on your / (root) filesystem since it is the only one that gets mounted read only at boot time and hence the only one that would try and be remounted read/write

[jpollard]

5 C/ Get rid of /tmp

No complaints over the basics.

But I've never seen the X server write short files to /tmp other than the
creation (one time only) of the directory .X11-unix, .X0-lock.

These (and other .X?-lock) files are created only if needed, and if they
already exist, they are not created again. The files in /tmp/.X11-unix
are domain socket references only (no data). the files /tmp/.X?lock
are used for locking references to the socket files. Again, no data.

Now moving /tmp to ramdisk is fine - but you better have enough
swap space somewhere (or lots of free memory) because you can get
into a deadlock/random application aborts because of of it. Web browsers
need to put work files somewhere (pdf files are nasty about that), and
a number of gnome/kde utilities/user daemons will put their workfiles
there too (though these are fairly small - on my system most of these
are 4 bytes long). It may be these files you are referring to.

[stevea]

Just a question on this one. What if you have a combination of SSD and regular rotating disks? Would the elevator=noop kernel parameter cause the regular disks to start using the unsorted seek order which would very noticeably drop the performance on those drives?

If it would, then I guess you would then have to weigh which gives you the best overall performance. Increasing it on the SSD and dropping it on the platter drive, or keeping it beneficial to the platter drive at the probably lower drop in performance on the SSD.

Excellent question. If you have a mix or rotating and SSD drives, then the thing to do is to create a different schedule algorithm for each drive.

Perhaps you'd like to leave the default in place (no change to the grub.conf) and use his command

echo "noop" > /sys/block/sda/queue/scheduler
in /etc/rc.d/rc.local.

The command above will only change the schedule algorithm for drive 'sda'.


It's also possible and reasonable to make this change by editing /etc/sysctl.conf and adding a line like ...
block.sda.queue.scheduler = noop

The use of sysctl is NOT possible.

[DBelton]

Great stevea! So it is possible to set that on a per drive basis rather than an "all or nothing" type of deal. That is great information there.

Thanks!

Edit:
Another thing, too. With so many people starting to use SSD's now... Possibly this could be moved over to "Guides & Solutions (No Questions)" and maybe even stickied?

[stevea]

yes, you set the noatime in the options in fstab.

like so:

LABEL=Drive\040K /media/Drive_K ext4 defaults,noatime 0 0

However, I have heard of some having problems trying to set data=writeback in /etc/fstab if it's not the default for the drive. It seems that on boot, the filesystem gets mounted read only, then it's remounted read/write. I've heard of some problem with it not being about to change that option on a remount. It may be fixed now, though.

You will probably want to set the journalling options as stevea has shown above.

Edit: I should have said that the problem above would only occur if you were trying to set journalling options on your / (root) filesystem since it is the only one that gets mounted read only at boot time and hence the only one that would try and be remounted read/write

The root file system "/" is initially mounted "ro" and then remounted according to fstab; has been for many many years. This does not preclude using any of the options shown. I think there is some confusion on this complex issue. The journal mode of an ext3/4 rootfs cannot be changed after the mount. See the "rootflags=data=writeback" description in post #1.

The ext3/ext4 journal allows the file system to be repaired readily in case of a crash or unexpected power loss. ext3 and ext4 file systems can be created without any journal or modified to not have a journal as described in post 1. These can also be mounted with journalling disabled using the "noload" option, which might be the most flexible approach.

Obviously without journalling there are fewer disk writes. The ext3/4 file system mount takes several journal options including a "data=writeback" option which allows for optimal throughput, unordered journal writes, but recent writes may be lost, though FS integrity preserved.

If you wish to keep the journal, and wish to have optimal throughput, and can accept losing some of the last writes in case of a crash, then then the "data=writeback" is a reasonable choice. Otherwise the default "data=ordered" does a better job preserving late writes after a crash.

The decision to use avoid journalling is sadly an important means of reducing writes, but also the journal creates a very important means of recovering from crashes. For modern disks and the modern Linux kernel thankfully the need for a fsck is quite rare, but without a journal the result can be costly and could result in a complete loss of the file system.

DO NOT run without a journal until you clearly understand the potential loss of the entire FS and have a good practical plan for that eventuality.

5 C/ Get rid of /tmp

No complaints over the basics.

But I've never seen the X server write short files to /tmp other than the
creation (one time only) of the directory .X11-unix, .X0-lock.

These (and other .X?-lock) files are created only if needed, and if they
already exist, they are not created again. The files in /tmp/.X11-unix
are domain socket references only (no data). the files /tmp/.X?lock
are used for locking references to the socket files. Again, no data.

JP you are correct. X is writing regularly to the AF_LOCAL socket handle at /tmp/.X11-unix/X* but this does not cause on-disk changes, so my statement above is incorrect. What X does is create and modify inode entries in tmpfs (/dev/shm) and often at a high rate. Fortunately tmpfs is also a memory based file system to is avoids wearing the SSD drive.

One can easily see all the block writes on a system using this command (as root):
echo 1 > /proc/sys/vm/block_dump
and then looking through the "dmesg" command output. [[This mechanism creates a large dmesg file in a hurry, so it should be turned off with "echo 0 > ..." after a few minutes.]]

We can regularly see patterns like ....

[105484.780246] X(1618): dirtied inode 1453894 (?) on tmpfs
[105484.796435] X(1618): dirtied inode 1453907 (?) on tmpfs
[105484.808977] X(1618): dirtied inode 1453912 (?) on tmpfs
[105487.770635] X(1618): dirtied inode 1453944 (?) on tmpfs
[105488.213089] X(1618): dirtied inode 1453946 (?) on tmpfs
[105488.213250] X(1618): dirtied inode 1453945 (?) on tmpfs
[105488.213861] X(1618): dirtied inode 1453949 (?) on tmpfs
[105488.213898] X(1618): dirtied inode 1453952 (?) on tmpfs
[105488.214032] X(1618): dirtied inode 1453955 (?) on tmpfs
[105488.214109] X(1618): dirtied inode 1453959 (?) on tmpfs
[105488.214163] X(1618): dirtied inode 1453958 (?) on tmpfs
[105488.214317] X(1618): dirtied inode 1453964 (?) on tmpfs
[105488.215022] X(1618): dirtied inode 1453967 (?) on tmpfs
[105488.215216] X(1618): dirtied inode 1453970 (?) on tmpfs
[105488.218509] X(1618): dirtied inode 1454002 (?) on tmpfs
[105488.238657] X(1618): dirtied inode 1454012 (?) on tmpfs
[105488.239632] X(1618): dirtied inode 1454017 (?) on tmpfs
[105488.240157] X(1618): dirtied inode 1454022 (?) on tmpfs

18 inodes modified in a few seconds, but on tmpfs. A dirtied inode is not automatically a disk write, but the recently revised kernel flush daemons circumvent a lot of "lazy update" policies that were possible in the past.

Sadly we still see long streams of firefox I/O even after the changes in post#1.

[105063.153633] firefox(2399): WRITE block 15548872 on sda3
[105063.153654] firefox(2399): WRITE block 15548880 on sda3
[105063.153825] firefox(2399): WRITE block 8389248 on sda3
[105063.153969] firefox(2399): WRITE block 15548872 on sda3
[105063.154132] firefox(2399): WRITE block 5556920 on sda3
[105063.154516] firefox(2399): WRITE block 15552672 on sda3
[105063.154527] firefox(2399): WRITE block 15552680 on sda3
[105063.154534] firefox(2399): WRITE block 15552688 on sda3
[105063.154647] firefox(2399): WRITE block 8389248 on sda3
[105063.154778] firefox(2399): WRITE block 15552672 on sda3
{~ 20 omitted)

Of course we want firefox to store recent history and new bookmarks to SSD, but it seems to be using disk beyond these.

Also the recently implemented changes to the kernel flush daemon cause frequent flushing of blocks to disk, so we see sequences like ...

[104361.279609] flush-8:0(1624): WRITE block 8 on sda3
[104361.279628] flush-8:0(1624): WRITE block 8388736 on sda3
[104361.279637] flush-8:0(1624): WRITE block 8389144 on sda3
[104361.279644] flush-8:0(1624): WRITE block 8389192 on sda3
[104361.279684] flush-8:0(1624): WRITE block 8389248 on sda3
[104361.279692] flush-8:0(1624): WRITE block 8389864 on sda3
[104361.279699] flush-8:0(1624): WRITE block 8391984 on sda3
[104361.279705] flush-8:0(1624): WRITE block 8455736 on sda3
[104361.279727] flush-8:0(1624): WRITE block 12583000 on sda3
[104361.279734] flush-8:0(1624): WRITE block 12583008 on sda3

at irregular intervals.

Still the steps indicated do cause a substantial reduction in disk writes.



The problem with /tmp is different than I had stated. There are a large number of files opened. For example, at this moment I have a fairly spartan gnome desktop running (firefox and two gnome-terminals) and yet ...
lsof | grep /tmp/ | wc -l
reports 135 files currently opened in /tmp. 109 of these are AF_LOCAL sockets handles for desktop gui apps and the other 26 regular files are for gnome-terminal, cupsd, and a handful of panel applets. Of course these files are created and deleted with the associated processes. The total space used by these is modest, even including the directory space used.

A more troubling use of /tmp is that browsers and similar apps write large temporary files to /tmp and writing these to SSD is undesirable.

Now moving /tmp to ramdisk is fine - but you better have enough
swap space somewhere (or lots of free memory) because you can get
into a deadlock/random application aborts because of of it. Web browsers
need to put work files somewhere (pdf files are nasty about that), and
a number of gnome/kde utilities/user daemons will put their workfiles
there too (though these are fairly small - on my system most of these
are 4 bytes long). It may be these files you are referring to.

To be clear, Linux has a tmpfs block device and also a ramdisk block device(see "man ram"). The example in post #1 uses the tmpfs block device to implement /tmp.

The tmpfs block device is more flexible than ramdisk with respect to memory use. tmpfs only uses the amount of DRAM needed (not a fixed allocation). tmpfs has a lot of maximum size options and defaults to half of DRAM size as the maximum. In case memory pressure exists, then tmpfs pages can be moved to swap. Any swap use is undesirable, but if moving some dowloaded pdf file from /tmp to swap means the system can continue that's a reasonable compromise, and it certainly creates fewer SSD writes then downloading to SSD based /tmp.

JP notes a glaring flaw in modern /tmp usage. Most browsers will drop .pdf files, image files, spreadsheets, .doc files and so on into /tmp for temporary usage, for example to bring up a helper application or plugin. So it's not uncommon to have a few hundred MB of "cruft" files in /tmp. Since disk based /tmp is never cleaned these large downloaded files occupy disk space for months or even years.

Mitigating the problem of using tmpfs for /tmp, and it becoming filled are:
A tmpfs based /tmp is cleaned on every shutdown so the "cruft" can't accumulate longer than "uptime".
Any reasonable person investing in a (currently expensive) SSD drive should already have addressed DRAM limitations of their system.

I don't think that filling /tmp on tmpfs is a more likely issue than filling /tmp on disk for anyone who has 1GB or more and can avoid regular use of swap.

[DBelton]

The root file system "/" is initially mounted "ro" and then remounted according to fstab; has been for many many years. This does not preclude using any of the options shown. I think there is some confusion on this complex issue.

The ext3/ext4 journal allows the file system to be repaired readily in case of a crash or unexpected power loss. ext3 and ext4 file systems can be created without any journal or modified to not have a journal as described in post 1. These can also be mounted with journalling disabled using the "noload" option, which might be the most flexible approach.

Obviously without journalling there are fewer disk writes. The ext3/4 file system mount takes several journal options including a "data=writeback" option which allows for optimal throughput, unordered journal writes, but recent wrtes may be lost, though FS integrity preserved.

If you wish to keep the journal, and wish to have optimal throughput, and can accept losing some of the last writes in case of a crash, then then the "data=writeback" is a reasonable choice. Otherwise the default "data=ordered" does a better job preserving late writes after a crash.

The decision to use avoid journalling is sadly an important means of reducing writes, but also the journal creates a very important means of recovering from crashes. For modern disks and the modern Linux kernel thankfully the need for a fsck is quite rare, but without a journal the result can be costly and could result in a complete loss of the file system.

DO NOT run without a journal until you clearly understand the potential loss of the entire FS and have a good practical plan for that eventuality.

The problems I had heard about aren't with changing the journalling options. You are correct there. It's not a problem to change them.

What I was referring to was the initial mount of the root filesystem as readonly sets the journalling options on the drive according to the defaults for the drive. Then when it hits where it processes /etc/fstab and switches the mount to read/write, I believe it does a remount rather than a complete umount then a new mount as read/write. The remount was where the problems occurred. For some reason, it got messed up if you tried to change the journalling options while the drive was mounted.

This may have been corrected since it was a little while back that I was hearing about the problem.

I know it SHOULD work to set the journalling options for the root filesystem in /etc/fstab. I was just noting that it was probably a safer alternative to set the journalling type the way you mentioned above instead. That way it doesn't try to change it during the remount.

The problem I saw has probably been fixed as the potential to corrupt the root filesystem is too big of a bug for them to leave unfixed for any time at all, so all of my babbling here is probably about nothing.

[stevea]

Good memory DB' The problem was with "mount" and was corrected ~2 years ago.

http://kerneltrap.org/mailarchive/li.../11/28/4259514

[vyvepe]

Users frequently ask "What about swap ?". The swap manager does not
manage TRIM at all, ...

Are you sure about swap partitions not getting TRIM commands?
The documentation here:
http://docs.redhat.com/docs/en-US/Re...ssdtuning.html
states:

The Linux swap code will issue TRIM commands to TRIM-enabled devices, and there is no option to control this behaviour.

Is the documentation there wrong?

[stevea]

Are you sure about swap partitions not getting TRIM commands?
...
Is the documentation there wrong?

Your link is essentially correct about swap. There was some very early (2008) swap-TRIM support but that was all ripped out once drives supporting TRIM arrived and I was unaware of it's complete replacement. Also I see that btrfs and FAT file systems have some level of TRIM support now. Your RHEL6 link makes some claims about erase-page alignment that may not be accurate (manufacturers are very tight-lipped on the topic). Also please remember that RHEL6 kernel features are not necessarily those of the numerically identical vanilla kernel, nor of any particular Fedora release.

I've re-reviewed the kernel source and will modify post #1 based on your excellent input, Vyvepe.

[buckyb]

Should TRIM be enabled on the SATA III SSDs?

[stevea]

Should TRIM be enabled on the SATA III SSDs?

Yes, absolutely. You should enable TRIM on any SSD drive that supports it - and that includes nearly every drive released since mid-2010.
http://en.wikipedia.org/wiki/TRIM
If you fail to use TRIM then the drive will become increasingly sluggish on writes as garbage collection and "write amplification" will occur.

To enable trim, use the "discard' mount option in fstab for all mounted partitions from the SSD. The "swap" partition automatically uses TRIM. For example from /etc/fstab ....

UUID=ffc6a6fc-1bf3-4f25-ab17-067b0515e85a /	ext4	noatime,discard,data=writeback	1 1
UUID=24941fe7-6d23-4969-951e-0872d4b81b0e /home	ext4	noatime,discard,data=writeback	1 2
UUID=2bbebe51-c0f8-4296-ba0a-e715bf84dc67 swap	swap	defaults			0 0

[dd_wizard]

I've been curious about something I read, but I can't find the page again. I think it was on thessdreview.com, or maybe anandtech. The article quoted either a Microsoft or Intel engineer who stated that between 50% and 60% of disk I/O operations were 4k (NTFS block size) writes. That may well be the case in Windows, but I'm wondering how accurately it applies to linux. Here's the closest thing I've been able to produce under F15:

$ sar -d -p

15:20:01           DEV               tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
Average:           sda              5.73    218.33     74.57     51.12      0.53     91.64      7.95      4.56
Average:    vg_mobilepc-lv_root     3.31    117.67      0.67     35.77      0.31     93.75      4.63      1.53
Average:    vg_mobilepc-lv_swap     3.36      9.39     17.45      8.00      0.06     17.33      0.68      0.23
Average:    vg_mobilepc-lv_home     6.40     23.19     45.08     10.66      0.37     58.32      3.20      2.05
Average:    vg_mobilepc-lv_var      2.83     68.02     11.37     28.05      0.19     66.88      3.88      1.10

According to the man page for sar, those sizes are 512 byte sectors. It's apparent that there are a lot more reads than writes on my laptop than the article described. Also, the average size is a lot bigger than 4kB, 51.2 * 512B = 25.6kB.

I do have /tmp and /var/tmp mounted as tmpfs. Also, I have firefox's cache in /tmp, so it's in a tmpfs as well. Since sar doesn't monitor tmpfs, I'm really curious what other users see when /tmp, /var/tmp, and firefox's cache are on a physical drive.

dd_wizard