{{Article summary text|This article covers many aspects of SSDs (solid state drives) as they relate to Linux; however, the underlying principals and key learning presented within are general enough to be applicable to users running SSDs on other operating systems such as the Windows family of products as well as Mac OS X. Beyond the aforementioned information, Linux users will benefit from the tweaks/optimization presented herein.}}

+

{{Related articles start}}

−

{{Article summary heading|Related Articles}}

+

{{Related|Solid State Drive/NVMe}}

−

{{Article summary wiki|SSD Benchmarking}}

+

{{Related|Solid State Drive/Memory cell clearing}}

−

{{Article summary wiki|SSD Memory Cell Clearing}}

+

{{Related|Benchmarking/Data storage devices}}

−

{{Article summary wiki|profile-sync-daemon}}

+

{{Related|Improving performance#Storage devices}}

−

{{Article summary end}}

+

{{Related|Flashcache}}

+

{{Related articles end}}

+

This article covers special topics for operating [[Wikipedia:Solid-state drive|Solid State Drives]] (SSDs) and other flash-memory based storage devices. If you want to partition an SSD for a specific purpose, it may be useful to consider the [[Wikipedia:List of file systems#File systems optimized for flash memory, solid state media|List of file systems optimized for flash memory]]. For general usage, you should simply choose your preferred [[filesystem]].

−

==Introduction==

+

== Usage ==

−

Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to set up SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.

−

{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using other operating systems like BSD, Mac OS X or Windows.}}

*Minimal power consumption - fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.

−

*Light-weight - ideal for laptops.

−

===Limitations===

+

Most SSDs support the [[wikipedia:TRIM|ATA_TRIM command]] for sustained long-term performance and wear-leveling. A [https://www.techspot.com/review/737-ocz-vector-150-ssd/page9.html techspot article] shows performance benchmark examples of before and after filling an SSD with data.

*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.

−

*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size are not autodetected.

−

*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.

−

*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes are not amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell does not lose its contents over time.

−

*Performance can drop as the disk gets filled. Garbage collection is not universally well implemented, meaning freed space is not always collected into entirely free cells.

−

==Pre-Purchase Considerations==

+

As of Linux kernel version 3.8 onwards, support for TRIM was continually added for the different [[filesystems]]. See the following table for an indicative overview:

−

There are several key features to look for prior to purchasing a contemporary SSD.

−

===Key Features===

−

*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.

−

*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.

−

===Reviews===

+

{| class="wikitable"

−

This section is not meant to be all-inclusive, but does capture some key reviews.

{{Note|There are different types of TRIM support defined by the specification. Hence, the output may differ depending what the drive supports. See [[Wikipedia:TRIM#ATA]] for more information.}}

+

+

==== Periodic TRIM ====

+

+

The {{Pkg|util-linux}} package provides {{ic|fstrim.service}} and {{ic|fstrim.timer}} [[systemd]] unit files. [[Enabling]] the timer will activate the service weekly. The service executes {{man|8|fstrim}} on all mounted filesystems on devices that support the ''discard'' operation.

+

+

The timer relies on the timestamp of {{ic|/var/lib/systemd/timers/stamp-fstrim.timer}} (which it will create upon first invocation) to know whether a week has elapsed since it last ran. Therefore there is no need to worry about too frequent invocations, in an ''anacron''-like fashion.

+

+

To query the units activity and status, see [[journalctl]]. To change the periodicity of the timer or the command run, [[edit]] the provided unit files.

+

+

==== Continuous TRIM ====

+

+

{{Warning|Unfortunately, there are wide quality gaps of SSD's bios' to perform continuous TRIM, which is also why using the {{ic|discard}} mount flag is [https://forums.freebsd.org/threads/56951/#post-328912 recommended against] generally by ext filesystem developer Theodore Ts'o. If in doubt about your hardware, apply [[#Periodic TRIM]] instead.}}

+

+

{{Note|Before [[Wikipedia:Serial ATA#SATA revision 3.1|SATA 3.1]] all TRIM commands were synchronous, so continuous trimming would produce frequent system freezes. In this case, applying [[#Periodic TRIM]] less often is better alternative. Similar issue holds also for a [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4522 number of devices], for which queued TRIM command execution was blacklisted due to [https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ serious data corruption]. See [[Wikipedia:Trim (computing)#Shortcomings]] for details.}}

+

+

Using the {{ic|discard}} option for a mount in {{ic|/etc/fstab}} enables continuous TRIM in device operations:

+

+

/dev/sda1 / ext4 defaults,'''discard''' 0 1

+

+

The main benefit of continuous TRIM is speed; an SSD can perform more efficient [https://arstechnica.com/gadgets/2015/04/ask-ars-my-ssd-does-garbage-collection-so-i-dont-need-trim-right/ garbage collection]. However, results vary and particularly earlier SSD generations may also show just the opposite effect. Also for this reason, some distributions decided against using it (e.g. Ubuntu: see [https://www.phoronix.com/scan.php?page=news_item&px=MTUxOTY this article] and the [https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming related blueprint]).

+

+

{{Note|There is no need for the {{ic|discard}} flag if you run {{ic|fstrim}} periodically.}}

+

+

On the ext4 filesystem, the {{ic|discard}} flag can also be set as a [[Access_Control_Lists#Enabling_ACL|default mount option]] using ''tune2fs'':

+

+

# tune2fs -o discard /dev/sd'''XY'''

+

+

Using the default mount options instead of an entry in {{ic|/etc/fstab}} is useful for external drives, because such partition will be mounted with the default options also on other machines. There is no need to edit {{ic|/etc/fstab}} on every machine.

+

+

{{Note|The default mount options are not listed in {{ic|/proc/mounts}}.}}

+

+

==== Trim an entire device ====

+

+

If you want to trim your entire SSD at once, e.g. for a new install, or you want to sell your SSD, you can use the blkdiscard command, which will instantly discard all blocks on a device.

+

+

{{Warning|all data on the device will be lost!}}

+

+

# blkdiscard /dev/sd''X''

+

+

==== LVM ====

+

+

Change the value of {{ic|issue_discards}} option from 0 to 1 in {{ic|/etc/lvm/lvm.conf}}.

+

+

{{Note|Enabling this option will "issue discards to a logical volumes's underlying physical volume(s) when the logical volume is no longer using the physical volumes' space (e.g. ''lvremove'', ''lvreduce'', etc)" (see {{man|5|lvm.conf}} and/or inline comments in {{ic|/etc/lvm/lvm.conf}}). As such it does not seem to be required for "regular" TRIM requests (file deletions inside a filesystem) to be functional.}}

+

+

==== dm-crypt ====

+

+

{{Warning|The discard option allows discard requests to be passed through the encrypted block device. This improves performance on SSD storage but has security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.}}

+

+

For non-root filesystems, configure {{ic|/etc/crypttab}} to include {{ic|discard}} in the list of options for encrypted block devices located on an SSD (see [[dm-crypt/System configuration#crypttab]]).

−

==Tips for Maximizing SSD Performance==

+

For the root filesystem, follow the instructions from [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] to add the right kernel parameter to the bootloader configuration.

−

===Mount Flags===

−

There are several key mount flags to use in one's {{ic|/etc/fstab}} entries for SSD partitions.

−

*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.

+

=== Maximizing performance ===

−

** However, this will cause issues with some programs such as [[Mutt]], as the access time of the file will eventually be previous than the modification time, which would make no sense. Using the '''relatime''' option instead of noatime will ensure that the atime field will never be prior to the last modification time of a file.

−

*'''discard''' - The discard flag will enable the benefits of the TRIM command as long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.

−

/dev/sda1 / ext4 defaults,relatime,discard 0 1

+

Follow the tips in [[Improving performance#Storage devices]] to maximize the performance of your drives.

−

/dev/sda2 /home ext4 defaults,relatime,discard 0 1

−

{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the {{ic|discard}} flag. Data loss can occur otherwise!}}

+

=== Security ===

−

===Enable TRIM With mkfs.ext4 or tune2fs (Discouraged) ===

+

==== Hdparm shows "frozen" state ====

−

One can set the trim flag statically with tune2fs or when the filesystem is created.

−

# tune2fs -o discard /dev/sdXY

−

or

−

# mkfs.ext4 -E discard /dev/sdXY

−

{{Note|After this option is set as described above, any time the user checks mounted filesystems with "mount", the discard option will not show up. Even when discard is passed on the CLI in addition to the option being set with tune2fs or mkfs.ext4, it will not show up. See the following thread for a discussion about his: https://bbs.archlinux.org/viewtopic.php?id&#61;137314 }}

+

Some motherboard BIOS' issue a "security freeze" command to attached storage devices on initialization. Likewise some SSD (and HDD) BIOS' are set to "security freeze" in the factory already. Both result in the device's password security settings to be set to '''frozen''', as shown in below output:

−

===Apply TRIM via cron===

+

{{hc|head=# hdparm -I /dev/sda |output=

−

Enabling TRIM on supported SSDs is definitely recommended. But sometimes it may cause some SSDs to [https://patrick-nagel.net/blog/archives/337 perform slowly] during deletion of files. If this is the case, one may choose to use fstrim as an alternative.

+

Security:

−

# fstrim -v /

+

Master password revision code = 65534

−

The partition for which fstrim is to be applied must be mounted, and must be inidcated by the mount point.

If this method seems like a better alternative, it might be a good idea to have this run from time to time using cron. To have this run daily, the default cron package (cronie) includes an anacron implementation which, by default, is set up for hourly, daily, weekly, and monthly jobs. To add to the list of daily cron tasks, simply create a script that takes care of the desired actions and put it in /etc/cron.daily, /etc/cron.weekly, etc. Appropriate nice and ionice values are recommended if this method is chosen. If implemented, you may remove the "discard" option from your fstab.

+

Operations like formatting the device or installing operating systems are not affected by the "security freeze".

−

{{Note|Use the 'discard' mount option as a first choice. This method should be considered second to the normal implementation of TRIM.}}

+

The above output shows the device is '''not locked''' by a HDD-password on boot and the '''frozen''' state safeguards the device against malwares which may try to lock it by setting a password to it at runtime.

−

=== I/O Scheduler ===

+

If you intend to set a password to a "frozen" device yourself, a motherboard BIOS with support for it is required. A lot of notebooks have support, because it is required for [[Wikipedia:Hardware-based_full_disk_encryption|hardware encryption]], but support may not be trivial for a desktop/server board. For the Intel DH67CL/BL motherboard, for example, the motherboard has to be set to "maintenance mode" by a physical jumper to access the settings (see [https://sstahlman.blogspot.in/2014/07/hardware-fde-with-intel-ssd-330-on.html?showComment=1411193181867#c4579383928221016762], [https://communities.intel.com/message/251978#251978]).

−

Consider switching from the default [https://en.wikipedia.org/wiki/CFQ CFQ] scheduler (Completely Fair Queuing) since 2.6.18 to [http://en.wikipedia.org/wiki/NOOP_scheduler NOOP] or [http://en.wikipedia.org/wiki/Deadline_scheduler Deadline]. The latter two offer performance boosts for SSDs. The NOOP scheduler, for example, implements a simple queue for all incoming I/O requests, without re-ordering and grouping the ones that are physically closer on the disk. On SSDs seek times are identical for all sectors, thus invalidating the need to re-order I/O queues based on them.

−

For more on schedulers, see these: [http://www.linux-mag.com/id/7564 Linux Magazine article], [http://www.phoronix.com/scan.php?page=article&item=linux_iosched_2012 Phoronix benchmark] and {{Bug|22605}}.

+

{{Warning|Do not try to change the above '''lock''' security settings with {{ic|hdparm}} unless you know exactly what you are doing.}}

−

The CFQ scheduler is enabled by default on Arch. Verify this by viewing the contents {{ic|/sys/block/sdX/queue/scheduler}}:

+

If you intend to erase the SSD, see [[Securely wipe disk#hdparm]] and [[#SSD memory cell clearing]] below.

−

$ cat /sys/block/sdX/queue/scheduler

−

noop deadline [cfq]

−

The scheduler currently in use is denoted from the available schedulers by the brackets.

−

===== Kernel parameter (for a single device) =====

+

==== SSD memory cell clearing ====

−

If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the {{ic|1=elevator=noop}} kernel parameter. See [[Kernel parameters]] for more info.

−

===== Using the sys virtual filesystem (for multiple devices) =====

+

On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed thus restoring it to its [https://www.anandtech.com/show/2738/8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.

−

This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).

−

Add the following line in {{ic|/etc/rc.local}}:

−

echo noop > /sys/block/sdX/queue/scheduler

−

where X is the letter for the SSD device.

−

Because of the potential for udev to assign different {{ic|/dev/}} nodes to drives before and after a kernel update, users must take care that the NOOP scheduler is applied to the correct device upon boot. One way to do this is by using the SSD's device ID to determine its {{ic|/dev/}} node. To do this automatically, use the following snippet instead of the line above and add it to {{ic|/etc/rc.local}}:

+

The reset is easily accomplished in a three step procedure denoted on the [[SSD memory cell clearing]] wiki article. If the reason for the reset is to wipe data, you may not want to rely on the SSD bios to perform it securely. See [[Securely wipe disk#Flash memory]] for further information and examples to perform a wipe.

−

declare -ar SSDS=(

−

'scsi-SATA_SAMSUNG_SSD_PM8_S0NUNEAB861972'

−

'ata-SAMSUNG_SSD_PM810_2.5__7mm_256GB_S0NUNEAB861972'

−

)

−

−

for SSD in "${SSDS[@]}" ; do

−

BY_ID=/dev/disk/by-id/$SSD

−

−

if &#91;&#91; -e $BY_ID ]] ; then

−

DEV_NAME=`ls -l $BY_ID | awk '{ print $NF }' | sed -e 's/[/\.]//g'`

−

SCHED=/sys/block/$DEV_NAME/queue/scheduler

−

−

if &#91;&#91; -w $SCHED ]] ; then

−

echo noop > $SCHED

−

fi

−

fi

−

done

−

where {{ic|SSDS}} is a Bash array containing the device IDs of all SSD devices. Device IDs are listed in {{ic|/dev/disk/by-id/}} as symbolic links pointing to their corresponding {{ic|/dev/}} nodes. To view the links listed with their targets, issue the following command:

−

ls -l /dev/disk/by-id/

−

=====Using udev for one device or HDD/SSD mixed environment=====

+

==== Hardware encryption ====

−

Though the above will undoubtedly work, it is probably considered a reliable workaround. It should also be noted that with the move to [[systemd]] there will be no rc.local. Ergo, it would be preferred to use the system that is responsible for the devices in the first place to implement the scheduler. In this case it is udev, and to do this, all one needs is a simple [[udev]] rule.

−

To do this, create and edit a file in /etc/udev/rules.d named something like '60-schedulers.rules'. In the file include the following:

+

As noted in [[#Hdparm shows "frozen" state]] setting a password for a storage device (SSD/HDD) in the BIOS may also initialize the hardware encryption of devices supporting it. If the device also conforms to the OPAL standard, this may also be achieved without a respective BIOS feature to set the passphrase, see [[Self-Encrypting Drives]].

Of course, set deadline/cfq to the desired schedulers. Changes should occur upon next boot. To check success of the new rule:

−

$ cat /sys/block/sdX/queue/scheduler #where X is the device in question

−

{{note|Keep in mind cfq is the default scheduler, so the second rule with the standard kernel is not actually necessary. Also, in the example sixty is chosen because that is the number udev uses for its own persistent naming rules. Thus, it would seem that block devices are at this point able to be modified and this is a safe position for this particular rule. But the rule can be named anything so long as it ends in '.rules'. (Credit: falconindy and w0ng for posting on his blog)}}

+

== Troubleshooting ==

−

=== Swap Space on SSDs ===

+

It is possible that the issue you are encountering is a firmware bug which is not Linux specific, so before trying to troubleshoot an issue affecting the SSD device, you should first check if updates are available for:

−

One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swappiness" of the system thus avoiding writes to swap:

+

* The [[#Firmware|SSD's firmware]]

+

* The [[Flashing_BIOS_from_Linux|motherboard's BIOS/UEFI firmware]]

−

# echo 1 > /proc/sys/vm/swappiness

+

Even if it is a firmware bug it might be possible to avoid it, so if there are no updates to the firmware or you hesitant on updating firmware then the following might help.

−

Or one can simply modify {{ic|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article:

+

=== Resolving NCQ errors ===

−

vm.swappiness=1

+

Some SSDs and SATA chipsets do not work properly with Linux Native Command Queueing (NCQ). The tell-tale dmesg errors look like this:

On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.

The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.

+

To disable NCQ on boot, add {{ic|1=libata.force=noncq}} to the kernel command line in the [[bootloader]] configuration. To disable NCQ only for disk 0 on port 9 use: {{ic|1=libata.force=9.00:noncq}}

−

==Tips for Minimizing SSD Read/Writes==

+

Alternatively, you may disable NCQ for a specific drive without rebooting via sysfs:

−

An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.

−

{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}

+

# echo 1 > /sys/block/sdX/device/queue_depth

−

Use {{ic|iotop -oPa}} and sort by disk writes to see how much programs are writing to disk.

+

If this (and also updating the firmware) does not resolves the problem or cause other issues, then [[Reporting bug guidelines|file a bug report]].

−

=== Intelligent Partition Scheme ===

+

=== Resolving SATA power management related errors ===

−

*For systems with both an SSD and an HDD, consider relocating the {{ic|/var}} partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear.

−

*For systems with only an SSD (i.e. no HDDs), consider allocating a separate partition for {{ic|/var}} to allow for better crash recovery for example in the event of a broken program wasting all the space on {{ic|/}} or if some run away log file maxes out the space, etc.

−

=== The noatime Mount Flag ===

+

Some SSDs (e.g. Transcend MTS400) are failing when SATA Active Link Power Management, [[wikipedia:Aggressive Link Power Management|ALPM]], is enabled.

−

Assign the {{ic|noatime}} flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section above for more.

+

ALPM is disabled by default and enabled by a power saving daemon (e.g. [[TLP]], [[Laptop Mode Tools]]).

−

=== Locate High-Use Files to RAM ===

+

If you are starting to encounter SATA related errors when using such a daemon, you should try to disable ALPM by setting its state to {{ic|max_performance}} for both battery and AC powered profiles.

−

==== Browser Profiles ====

−

One can ''easily'' mount browser profile(s) such as chromium, firefox, opera, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.

−

The AUR contains several packages to automate this process, for example {{AUR|profile-sync-daemon}}.

+

== Firmware ==

−

==== Others ====

+

=== ADATA ===

−

For the same reasons a browser's profile can be relocated to RAM, so can highly used directories such as {{ic|/srv/http}} (if running a web server). A sister project to {{AUR|profile-sync-daemon}} is {{AUR|anything-sync-daemon}}, which allows users to define '''any''' directory to sync to RAM using the same underlying logic and safe guards.

−

{{Warning|Do NOT attempt to add /var/log to anything-sync-daemon. Systemd gets really pissed if you do.}}

+

ADATA has a utility available for Linux (i686) on their [http://www.adata.com.tw/index.php?action=ss_main&page=ss_content_driver&lan=en support page]. The link to latest firmware will appear after selecting the model. The latest Linux update utility is packed with firmware and needs to be run as root. One may need to set correct permissions for binary file first.

−

=== Compiling in tmpfs ===

+

=== Crucial ===

−

Intentionally compiling in {{ic|/tmp}} is a great idea to minimize this problem. For systems with >4 GB of memory, the tmp line in {{ic|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the {{ic|1=size=}} flag as {{ic|/tmp}} keeps filling up.

−

Example of a machine with 8 GB of physical memory:

+

Crucial provides an option for updating the firmware with an ISO image. These images can be found after selecting the product on their [http://www.crucial.com/usa/en/support-ssd SSD support page] and downloading the "Manual Boot File."

−

tmpfs /tmp tmpfs nodev,nosuid,size=7G 0 0

−

=== Disabling Journaling on the filesystem ===

+

{{Note|ISO images provided by Crucial does not seem to be hybrid. If you will use just the {{ic|dd}} command to copy the image to some device, the [[MBR]] won't be present, making such device unbootable.}}

−

Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://tytso.livejournal.com/61830.html Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:

−

'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''

+

Owners of an M4 Crucial model, may check if a firmware upgrade is needed with {{ic|smartctl}}.

Users seeing this warning are advised to backup all sensible data and '''consider upgrading immediately'''. Check [http://www.rojtberg.net/1008/updating-crucial-mx100-firmware-with-ubuntu/ this instructions] to update Crucial MX100 firmware by using the ISO image and Grub.

−

|199.4

−

|3.95 %

−

|-

−

!make clean

−

|6.45

−

|3.73

−

|42.17 %

−

|}

−

''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''

+

=== Intel ===

−

{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in tmpfs as recommended in the [[Solid_State_Drives#Compiling_in_tmpfs|preceding section]] of this article!}}

+

Intel has a Linux live system based [https://downloadcenter.intel.com/download/18363 Firmware Update Tool] for operating systems that are not compatible with its [https://downloadcenter.intel.com/download/18455 Intel® Solid-State Drive Toolbox] software.

−

=== Choice of Filesystem ===

+

=== Kingston ===

−

Many options exist for file systems including Ext2/3/4, Btrfs, etc.

−

==== Btrfs ====

+

Kingston has a Linux utility to update the firmware of Sandforce controller based drives: [https://www.kingston.com/en/support/technical/category/ssd SSD support page]. Click the images on the page to go to a support page for your SSD model. Support specifically for, e.g. the SH100S3 SSD, can be found on [https://www.hyperxgaming.com/us/support/technical/products?model=sh100s3 HyperX support page].

−

[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. Users are encouraged to read the [[Btrfs]] article for more info.

−

==== Ext4 ====

+

=== Mushkin ===

−

[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detect the disk nature; users must explicitly enable the TRIM command support using the {{ic|discard}} mount option in [[fstab]] (or with {{ic|tune2fs -o discard /dev/sdaX}}).

−

See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/filesystems/ext4.txt official in kernel tree documentation] for further information on ext4.

−

== SSD Benchmarking ==

+

The lesser known Mushkin brand Solid State drives also use Sandforce controllers, and have a Linux utility (nearly identical to Kingston's) to update the firmware.

−

See the [[SSD Benchmarking]] article for a general process of benchmarking SSDs or to see some of the SSDs in the database.

−

== Firmware Updates ==

=== OCZ ===

=== OCZ ===

−

OCZ has a command line utility available for Linux (i686 and x86_64) on their forum [http://www.ocztechnology.com/ssd_tools/ here].

+

+

OCZ has a [https://www.ocz.com/us/download/clout Command Line Online Update Tool (CLOUT)] available for Linux. The AUR provides {{AUR|ocz-ssd-utility}}, {{AUR|ocztoolbox}} and {{AUR|oczclout}}.

+

+

=== Samsung ===

+

+

Samsung notes that update methods other than using their Magician Software are "not supported," but it is possible. The Magician Software can be used to make a USB drive bootable with the firmware update. Samsung provides pre-made [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html bootable ISO images] that can be used to update the firmware. Another option is to use Samsung's {{AUR|samsung_magician}}, which is available in the AUR. Magician only supports Samsung-branded SSDs; those manufactured by Samsung for OEMs (e.g., Lenovo) are not supported.

+

+

{{Note|Samsung does not make it obvious at all that they actually provide these. They seem to have 4 different firmware update pages, and each references different ways of doing things.}}

+

+

Users preferring to run the firmware update from a live USB created under Linux (without using Samsung's "Magician" software under Microsoft Windows) can refer to [http://fomori.org/blog/?p=933 this post] for reference.

+

+

==== Native upgrade ====

+

+

{{Style|Assumes use of [[udisks]]; loop mounts can be done directly via [[mount]]}}

+

+

Alternatively, the firmware can be upgraded natively, without making a bootable USB stick, as shown below.

+

+

First visit the [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html Samsung downloads page] and download the latest firmware for Windows, which is available as a disk image. In the following, {{ic|Samsung_SSD_840_EVO_EXT0DB6Q.iso}} is used as an example file name, adjust it accordingly.

+

+

Setup the disk image:

+

+

$ udisksctl loop-setup -r -f Samsung_SSD_840_EVO_EXT0DB6Q.iso

+

+

This will make the ISO available as a loop device, and display the device path. Assuming it was {{ic|/dev/loop0}}:

+

+

$ udisksctl mount -b /dev/loop0

+

+

Get the contents of the disk:

+

+

$ mkdir Samsung_SSD_840_EVO_EXT0DB6Q

+

$ cp -r /run/media/$USER/CDROM/isolinux/ Samsung_SSD_840_EVO_EXT0DB6Q

+

+

Unmount the iso:

+

+

$ udisksctl unmount -b /dev/loop0

+

$ cd Samsung_SSD_840_EVO_EXT0DB6Q/isolinux

+

+

There is a FreeDOS image here that contains the firmware. Mount the image as before:

+

+

$ udisksctl loop-setup -r -f btdsk.img

+

$ udisksctl mount -b /dev/loop1

+

$ cp -r /run/media/$USER/C04D-1342/ Samsung_SSD_840_EVO_EXT0DB6Q

+

$ cd Samsung_SSD_840_EVO_EXT0DB6Q/C04D-1342/samsung

+

+

Get the disk number from magician:

+

+

# magician -L

+

+

Assuming it was 0:

+

+

# magician --disk 0 -F -p DSRD

+

+

Verify that the latest firmware has been installed:

+

+

# magician -L

+

+

Finally reboot.

+

+

=== SanDisk ===

+

+

SanDisk makes '''ISO firmware images''' to allow SSD firmware update on operating systems that are unsupported by their SanDisk SSD Toolkit. One must choose the firmware for the right ''SSD model'', as well as for the ''capacity'' that it has (e.g. 60GB, '''or''' 256GB). After burning the adequate ISO firmware image, simply restart the PC to boot with the newly created CD/DVD boot disk (may work from a USB stick).

+

+

The iso images just contain a linux kernel and an initrd. Extract them to {{ic|/boot}} partition and boot them with [[GRUB]] or [[Syslinux]] to update the firmware.

Note: There are different types of TRIM support defined by the specification. Hence, the output may differ depending what the drive supports. See Wikipedia:TRIM#ATA for more information.

Periodic TRIM

The util-linux package provides fstrim.service and fstrim.timersystemd unit files. Enabling the timer will activate the service weekly. The service executes fstrim(8) on all mounted filesystems on devices that support the discard operation.

The timer relies on the timestamp of /var/lib/systemd/timers/stamp-fstrim.timer (which it will create upon first invocation) to know whether a week has elapsed since it last ran. Therefore there is no need to worry about too frequent invocations, in an anacron-like fashion.

To query the units activity and status, see journalctl. To change the periodicity of the timer or the command run, edit the provided unit files.

Continuous TRIM

Warning: Unfortunately, there are wide quality gaps of SSD's bios' to perform continuous TRIM, which is also why using the discard mount flag is recommended against generally by ext filesystem developer Theodore Ts'o. If in doubt about your hardware, apply #Periodic TRIM instead.

Using the discard option for a mount in /etc/fstab enables continuous TRIM in device operations:

/dev/sda1 / ext4 defaults,discard 0 1

The main benefit of continuous TRIM is speed; an SSD can perform more efficient garbage collection. However, results vary and particularly earlier SSD generations may also show just the opposite effect. Also for this reason, some distributions decided against using it (e.g. Ubuntu: see this article and the related blueprint).

Note: There is no need for the discard flag if you run fstrim periodically.

Using the default mount options instead of an entry in /etc/fstab is useful for external drives, because such partition will be mounted with the default options also on other machines. There is no need to edit /etc/fstab on every machine.

Note: The default mount options are not listed in /proc/mounts.

Trim an entire device

If you want to trim your entire SSD at once, e.g. for a new install, or you want to sell your SSD, you can use the blkdiscard command, which will instantly discard all blocks on a device.

Warning: all data on the device will be lost!

# blkdiscard /dev/sdX

LVM

Change the value of issue_discards option from 0 to 1 in /etc/lvm/lvm.conf.

Note: Enabling this option will "issue discards to a logical volumes's underlying physical volume(s) when the logical volume is no longer using the physical volumes' space (e.g. lvremove, lvreduce, etc)" (see lvm.conf(5) and/or inline comments in /etc/lvm/lvm.conf). As such it does not seem to be required for "regular" TRIM requests (file deletions inside a filesystem) to be functional.

Maximizing performance

Security

Hdparm shows "frozen" state

Some motherboard BIOS' issue a "security freeze" command to attached storage devices on initialization. Likewise some SSD (and HDD) BIOS' are set to "security freeze" in the factory already. Both result in the device's password security settings to be set to frozen, as shown in below output:

Operations like formatting the device or installing operating systems are not affected by the "security freeze".

The above output shows the device is not locked by a HDD-password on boot and the frozen state safeguards the device against malwares which may try to lock it by setting a password to it at runtime.

If you intend to set a password to a "frozen" device yourself, a motherboard BIOS with support for it is required. A lot of notebooks have support, because it is required for hardware encryption, but support may not be trivial for a desktop/server board. For the Intel DH67CL/BL motherboard, for example, the motherboard has to be set to "maintenance mode" by a physical jumper to access the settings (see [5], [6]).

Warning: Do not try to change the above lock security settings with hdparm unless you know exactly what you are doing.

SSD memory cell clearing

On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed thus restoring it to its factory default write performance. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.

The reset is easily accomplished in a three step procedure denoted on the SSD memory cell clearing wiki article. If the reason for the reset is to wipe data, you may not want to rely on the SSD bios to perform it securely. See Securely wipe disk#Flash memory for further information and examples to perform a wipe.

Hardware encryption

As noted in #Hdparm shows "frozen" state setting a password for a storage device (SSD/HDD) in the BIOS may also initialize the hardware encryption of devices supporting it. If the device also conforms to the OPAL standard, this may also be achieved without a respective BIOS feature to set the passphrase, see Self-Encrypting Drives.

Troubleshooting

It is possible that the issue you are encountering is a firmware bug which is not Linux specific, so before trying to troubleshoot an issue affecting the SSD device, you should first check if updates are available for:

To disable NCQ on boot, add libata.force=noncq to the kernel command line in the bootloader configuration. To disable NCQ only for disk 0 on port 9 use: libata.force=9.00:noncq

Alternatively, you may disable NCQ for a specific drive without rebooting via sysfs:

# echo 1 > /sys/block/sdX/device/queue_depth

If this (and also updating the firmware) does not resolves the problem or cause other issues, then file a bug report.

Resolving SATA power management related errors

Some SSDs (e.g. Transcend MTS400) are failing when SATA Active Link Power Management, ALPM, is enabled.
ALPM is disabled by default and enabled by a power saving daemon (e.g. TLP, Laptop Mode Tools).

If you are starting to encounter SATA related errors when using such a daemon, you should try to disable ALPM by setting its state to max_performance for both battery and AC powered profiles.

Firmware

ADATA

ADATA has a utility available for Linux (i686) on their support page. The link to latest firmware will appear after selecting the model. The latest Linux update utility is packed with firmware and needs to be run as root. One may need to set correct permissions for binary file first.

Crucial

Crucial provides an option for updating the firmware with an ISO image. These images can be found after selecting the product on their SSD support page and downloading the "Manual Boot File."

Note: ISO images provided by Crucial does not seem to be hybrid. If you will use just the dd command to copy the image to some device, the MBR won't be present, making such device unbootable.

Owners of an M4 Crucial model, may check if a firmware upgrade is needed with smartctl.

Intel

Kingston

Kingston has a Linux utility to update the firmware of Sandforce controller based drives: SSD support page. Click the images on the page to go to a support page for your SSD model. Support specifically for, e.g. the SH100S3 SSD, can be found on HyperX support page.

Mushkin

The lesser known Mushkin brand Solid State drives also use Sandforce controllers, and have a Linux utility (nearly identical to Kingston's) to update the firmware.

OCZ

Samsung

Samsung notes that update methods other than using their Magician Software are "not supported," but it is possible. The Magician Software can be used to make a USB drive bootable with the firmware update. Samsung provides pre-made bootable ISO images that can be used to update the firmware. Another option is to use Samsung's samsung_magicianAUR, which is available in the AUR. Magician only supports Samsung-branded SSDs; those manufactured by Samsung for OEMs (e.g., Lenovo) are not supported.

Note: Samsung does not make it obvious at all that they actually provide these. They seem to have 4 different firmware update pages, and each references different ways of doing things.

Users preferring to run the firmware update from a live USB created under Linux (without using Samsung's "Magician" software under Microsoft Windows) can refer to this post for reference.

Native upgrade

Alternatively, the firmware can be upgraded natively, without making a bootable USB stick, as shown below.

First visit the Samsung downloads page and download the latest firmware for Windows, which is available as a disk image. In the following, Samsung_SSD_840_EVO_EXT0DB6Q.iso is used as an example file name, adjust it accordingly.

Setup the disk image:

$ udisksctl loop-setup -r -f Samsung_SSD_840_EVO_EXT0DB6Q.iso

This will make the ISO available as a loop device, and display the device path. Assuming it was /dev/loop0:

SanDisk

SanDisk makes ISO firmware images to allow SSD firmware update on operating systems that are unsupported by their SanDisk SSD Toolkit. One must choose the firmware for the right SSD model, as well as for the capacity that it has (e.g. 60GB, or 256GB). After burning the adequate ISO firmware image, simply restart the PC to boot with the newly created CD/DVD boot disk (may work from a USB stick).

The iso images just contain a linux kernel and an initrd. Extract them to /boot partition and boot them with GRUB or Syslinux to update the firmware.