SSDs, what do I need to know?

[Fourstar]

I've gone and got myself an OCZ Vertex 2E 120GB SSD from OcUK's one day special. I can now do my long overdue upgrade from the very soon to be obsoleted Ubuntu 9.04 and reorganise my other drives.

I am now wondering if there are any dos and don'ts with flash storage?
There seem to be plenty of rumours and myths out there, many of which may have been true with 1st Gen drives but could now be obsolete.

Maybe I'm just making a mountain out of a molehill and modern drives will have plenty of life in them regardless of write frequency.

Anyway, what are your thoughts on:

Aligning partitions
This seems like a faff but worth it.

Guide

Second guide which starts out explaining about alignment & Erase block sizes.
Calculator to go back and check a selected partition is aligned

Journaling on or off + noatime or relatime

Journaling adds additional writes but not that much in normal usage. Having the safety of the journal seems well worth it.

noatime looks to be best as the only references to things that may break with atime turned off is Mutt. I don't really care when my files were last accessed - at least I don't think I do.

Detailed blog entry on the matter by Theodore Ts'o complete with stats to back up his assertions.

Also read somewhere ext4 is the only filesystem that supports TRIM automatically.

/var, /tmp, swap
Should I be sticking these on a mechanical drive?

I/O Scheduler
Moving from the default anticipatory/cfq which are optimised for mechanical drives to the deadline scheduler will see a performance improvement.

See halfway down this post for full details.

Virtual Machines
I was thinking they would be great on the SSD.
Can set the VM's partitions to grow incrementally and as the SSD doesn't suffer from fragmentation all will be peachy.

I can't really find anything on this or if it is a good idea.

Swappiness
Hmm, if Linux is swapping inactive apps out of memory what is it caching instead?

Kernel swappiness is a controversial topic. The standard setting (60)
for kernel swappiness has the effect that inactive (but started) applications
will be moved to swap after some time. If the swap partition is placed
on a regular HDD in order to reduce wear of the SSD, then reloading the
application from swap can take several seconds. This causes annoying
delays and bad responsiveness of the system when you return from a
coffee break, for example. The solution is setting kernel swappiness
to zero, by adding a line vm.swappiness = 0 to /etc/sysctl.conf.
A temporary change for trying out the effect is possible by calling
echo 0 > /proc/sys/vm/swappiness (as root) from the command line.

Checking I/O traffic
Just for interests sake

If you want to know how much I/O traffic you have on the SSD, you can
check with iostat -m -d /dev/sda. This displays MB_read and MB_wrtn
for the given drive (measured since system startup). iostat also works
for individual partitions. It is provided by the sysstat package.

 

[SMN]

Randomly - Ive read a few reports that states BTRFS is one of the most optimized FS' for running on a SSD. Cant be verified (i intend on going BTRFS when i get my SSD when i can stomach parting with said pennies).

 

[PermaBanned]

Considering most Linux OS's run almost entirely in the RAM i'm not sure you'll see much of a performance increase.

And EXT3/4 doesn't suffer from fragmentation anyway...

 

[tntcoder]

Arch wiki has a great entry on SSDs, applicable to most distros.

I only have /var on a mech drive, didn't bother with /tmp. And might as well have swap on SSD as you should actually use the advantages of the drive rather than hide in the risk it will fail with a few too many reads /var is the main one though to keep off SSD imo.

Again, use journalling (with noatime) the benefits outweigh the risks.


Partition alignment is fairly important I think, it was a mother ****** to get working correctly though But the benchmarks show a worth while benefit. Hopefully this will get easier when fdisk catches up with the times.

 

[mortals]

/var, /tmp, swap
Should I be sticking these on a mechanical drive?

I have /tmp as a ramdisk on archlinux.

/etc/fstab

none                   /tmp          tmpfs     nodev,size=256M,nosuid  0 0

saves some reads/writes on hdd and also speeds up a lot of stuff.

I don't have a SSD as don't see much gain in the cost but would prob help a bit with ssd constant read/write

 

[Fourstar]

Randomly - Ive read a few reports that states BTRFS is one of the most optimized FS' for running on a SSD. Cant be verified (i intend on going BTRFS when i get my SSD when i can stomach parting with said pennies).

Interesting, though I think I'll wait a while for btrfs to mature further

And EXT3/4 doesn't suffer from fragmentation anyway...

Only to a point.

If you're creating 20GB virtual drives for use in Virtual Machines pre-allocating the space in a single block provides better performance than allowing the file to incrementally grow over the months.

On an SSD as there is no latency penalty for jumping to and from data located in different areas on the drive I was wondering if this might be a good match for incremental virtual drives.

Arch wiki has a great entry on SSDs, applicable to most distros.

Cheers, that is a great article.

And might as well have swap on SSD as you should actually use the advantages of the drive rather than hide in the risk it will fail

Very true, think I'll allocate the space on both SSD and HDD then see what differences I see after I've fiddled with swappiness to reduce the amount swapped out of RAM.

Partition alignment is fairly important I think, it was a mother ****** to get working correctly though

So I've read in various comments on OCZ's SSD forums. Should keep me amused for while