Overclock.net banner
1 - 20 of 38 Posts

· Registered
Joined
·
1,537 Posts
Discussion Starter · #1 ·
Having recently gone through the process of configuring an SSD for optimal use in Linux, I thought I'd post the steps I took for anyone in a similar situation
smile.gif


One of the main concerns with SSD's is that excessive writes may cause premature failure of the drive, so steps are taken to decrease the number of writes.

File System

The two most common file system types used with SSD's are Ext2 and Ext4. The difference between the two is journalling, Ext2 doesn't include journalling whereas Ext4, being the newest version, does.

What is journalling you may ask?

Journalling file systems keep track of the changes that are to be made to the hard disk in an area called the 'journal' before the changes are written to the disk. Error detection and recovery on a journalled file system is far greater than a file system without journalling; if an unexpected crash happens, the journal can be consulted to check for consistency.

Which File System Should I Use?

As we want to reduce the number of writes to the SSD, a file system without journalling would be the obvious choice, for example, Ext2. The only problem with Ext2, is that it lacks full TRIM support (TRIM discussed later in guide). Ext4 on the other hand, has full TRIM support, and has the option to turn the journal off.

Note: Without the journal, the hard drive will be more susceptible to errors after an unexpected freeze or shut down.

Disabling the Journal on Ext4:

To do this, you need to boot from a live CD/USB.

Open a terminal window and run:
Quote:
sudo tune2fs -O ^has_journal /dev/sda#
# = the number of the drive you want to remove the journal from, mine for example was 'sda5'.

Enable TRIM

TRIM is a command of an OS that handles functions such as garbage collection to prevent performance degradation over time.

Ext2 supports TRIM, but can only be operated manually whereas Ext4 supports it fully.

Enabling TRIM:

For starters make sure you're SSD supports TRIM (usually found on the manufacturers website), and you're OS supports TRIM too. TRIM is supported in Linux kernel 2.6.33 and later.

To check your kernel:
Quote:
Open Your /etc/fstab File
Quote:
sudo gedit /etc/fstab
(Assuming gedit is your text editor)

Look for 'ext4' and after it there should either be 'defaults' or 'errors=remount...'. Before that, add the word 'discard' so it looks like:
Quote:
discard,errors=remount
Manual TRIM

Important:

Not required if Linux Kernel is 2.6.33 or greater.
Ext2 file systems to not support online TRIM, in other words, it need to be mounted as read-only.

IF you're using an older kernel, the SSD will need to be TRIM'd manually, using software called 'hdparm'

To manually TRIM the SSD, start by downloading the latest hdparm from here.

After downloading, extract the tar.gz file.

Open a terminal window in the extracted folder and run:
Quote:
sudo make
Then:
Quote:
sudo make install
Navigate to:
Quote:
your download location/hdparm-9.37/wiper
Right click, and then 'open in terminal', alternatively navigate to the folder using the 'CD' command.

In the terminal window:
Quote:
sudo bash wiper.sh --commit /dev/sda#
'#' being the number of the hard drive you want to TRIM.

If not all required packages are required, an error will appear outlining what packages are required, install them and repeat the above.

Swap File

The swap file is an area of the hard drive the OS will use when it runs low on memory. How much the swap file is used is based on the 'swappiness', a number between 0 and 100. The higher the number, the more aggressively the OS will use the swap file. As we want to reduce the number of writes to the SSD, minimal use of the swap file would be best.

To edit swappiness:
Quote:
sudo gedit /etc/sysctl.conf
Look for 'vm.swappiness', if its not there:

At the bottom of the file, on a new line, add:
Quote:
vm.swappiness=1
Choose a low number, ideally less than 10, in my example I've chosen 1.

Noatime Option

By default, Linux will update all files and directories with a last access time, we want to disable this using the 'noatime' option.

Open your /etc/fstab file again:
Quote:
sudo gedit /etc/fstab
And where 'discard' was added previously, add 'noatime' before it:
Quote:
noatime,discard,errors=remount
Disk Scheduler

The disk scheduler handles how data is written to disk, the default disk scheduler will write files to disk based on their physical location, but since the write times on an SSD are not dependent on location, we want them to be written in the order they are received. We can do this using the 'noop' disk scheduler.

Enabling the 'noop' Disk Scheduler:
Quote:
sudo echo noop > /sys/block/sda/queue/scheduler
I hope this has been useful to anyone will Linux and an SSD
smile.gif
I've still got a bit to add when I have a little more time to spare.
 

· Registered
Joined
·
1,537 Posts
Discussion Starter · #3 ·
Quote:
Originally Posted by cavallino;12474886
Nice guide.

Question: Will I really be killing my SSD by leaving journaling disabled?

I did everything else in Arch for the ssd on my netbook but I have journaling enabled. The risk of error had me a bit worried because it's a laptop and there always the possibility of a rundown battery or something.
It's unlikely to be killing your SSD by keeping journalling on. It's a balance between reducing writes, and stability and reliability; and if you, like most, favour the latter then its probably best to keep journalling on.

Considering SSD's have only recently become viable for home users, the effects of long term use are yet to be fully analysed. Wait a few years and see
tongue.gif
 

· Registered
Joined
·
1,356 Posts
uhm... if you are disabling journaling on ext4 why not just run ext2 o_O more or less the same thing just no journaling
 

· Premium Member
Joined
·
14,563 Posts
A couple of notes:

If "defaults" appears in the fstab, you should completely replace it with your desired options (such as discard). If options other than discard appear, you should append them.

For instance: defaults change to discard; errors=remount change to discard,errors=remount

Second thing is, some applications really need atime, and so the noatime option will screw with them pretty badly. But you still lose a lot if you have atime enabled. The relatime option should be used instead.
 

· Registered
Joined
·
3 Posts
Two things I don't get
smile.gif
...

1. I'll try to use Debian with 2.6.32 kernel - so should I make both things from Enabling TRIM and Manual TRIM sections, or just the second one?

2. And also - when I install hdparm - should I run the last line from the Manual TRIM section periodically, or it'll be run automatically whenever it should?

Thank in advance, and also - great article
smile.gif


PS: A friendly advice - you can update the article with the answers of these two questions, so such confusions like mine get avoided later.
 

· Linux Lobbyist
Joined
·
2,108 Posts
Quote:
Originally Posted by petyrveliki View Post

Two things I don't get
smile.gif
...
1. I'll try to use Debian with 2.6.32 kernel - so should I make both things from Enabling TRIM and Manual TRIM sections, or just the second one?
2. And also - when I install hdparm - should I run the last line from the Manual TRIM section periodically, or it'll be run automatically whenever it should?
Thank in advance, and also - great article
smile.gif

PS: A friendly advice - you can update the article with the answers of these two questions, so such confusions like mine get avoided later.
To start off, this guide is a wee outdated (A lot of Linux SSD optimizations are automated on modern distributions. Its still a good practice to not rely on automatic configuration and read through the configuration files yourself and verify that things have been done properly)

For your first question, if you enable trim immediately after installing Linux to your SSD, there will be NO NEED to manually run trim operations for the lifetime of the installation. TRIM will automatically be performed whenever the OS is idle or resources are available to dedicate to TRIM, this is built into the Linux kernel.

For your second question this guide was written a while ago, and some of the information is deprecated. For modern Linux installations, the fstrim utility should be able to manually initiate file-system based TRIM requests, however as stated before, if you enable TRIM upon installation, you will not need to manually initiate trim. The fstrim utility can be useful to initiate a manual trim if the system has not been running trim operations during idle time for whatever reason and you start noticing diminishing performance.

And of course, what post would be productive without adding some insight to the topic and some additional information:

fstrim will likely become very useful in the early stages of NTFS-3g trim support with many users dual-booting Windows and Linux, since NTFS-3g doesn't support trim yet, those users will likely see moderate performance degradation if they are on their Linux system for extended periods of time, but only for files in the NTFS partition. The early iterations of TRIM for NTFS-3g will probably not allow for automatic TRIM (since it is potentially dangerous and could delete information) and will opt for manual TRIM via fstrim.

Interestingly VT-d systems running virtual machines of Windows 7 can give direct R/W access to the NTFS partitions and Windows will be able to initiate TRIM commands on target partitions correctly.

In the end, lack of TRIM support for NTFS partitions under Linux IS *NOT* a major pressing issue, since the second generation of consumer SSD's, most manufacturer's have opted for hardware level garbage collection, which is file system independent. Note that I said that users would likely see degradation - this is because idle garbage collection requires that the disk be IDLE. Since most *nix systems have at least some kind of disk activity at all times, even if you disable logging to the SSD and other such things, there will be very little time for the disk to initiate garbage collection.
 

· Registered
Joined
·
3 Posts
Quote:
Originally Posted by Xaero252 View Post

To start off, this guide is a wee outdated (A lot of Linux SSD optimizations are automated on modern distributions...
OK, great ... but I'm using Debian with 2.6.32 ... and so my first question didn't get any answer yet ...
redface.gif

Quote:
Originally Posted by Xaero252 View Post

For your first question, if you enable trim immediately after installing Linux to your SSD, there will be NO NEED to manually run trim operations for the lifetime of the installation. TRIM will automatically be performed whenever the OS is idle or resources are available to dedicate to TRIM, this is built into the Linux kernel.
Great ... but I'm still confused, because I'm with this specific kernel version - 2.6.32, and for enabling TRIM it's written down " TRIM is supported in Linux kernel 2.6.33 and later." and for manual TRIM "Not required if Linux Kernel is 2.6.33 or greater."

So, beeing with this specific kernel version - 2.6.32: I should do both?
It's still not clear for me ...

Thanks
smile.gif
 

· Registered
Joined
·
5,006 Posts
Hmm interesting, is there a way to monitor errors in the filesystem to decide if I want to turn Journaling off? It seems errors only really occur when the system shuts down improperly? I wonder how long fsck takes on an SSD...
 

· Linux Lobbyist
Joined
·
2,108 Posts
Most installs are set to run fsck periodically based on days since last run number of mounts or another determining factor. Usually they include repair of.the partition as well. You can obviously run fsck manually as well. Generally errors due to disabling journaling occur with unexpected power loss and can be prevented or completely avoided with a battery backup solution for clean shutdown.
 

· Registered
Joined
·
3 Posts
Quote:
Originally Posted by Plan9 View Post

tbh mate, you should upgrade your OS. It's not good running outdated software.
Well, this is the latest Debian, you know
smile.gif
... but I guess I'll choose another distro.

The problem is that the minimalistic ones are either too old - debian and centos use 2.6.32 - or too new - arch and gentoo are pretty unstable and break after update. And these are my requirements for the distro - very minimalistic, with a very minimal window manager. (Chose AwesomeWM for now.)
But have a SSD, so the first two - unfortunately - won't be options with this 2.6.32 kernel.

Thanks anyway
smile.gif
 
1 - 20 of 38 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top