Enter the SSD age

Hi,

I have been monitoring the SSD (Solid State Disk) market for a few months.

With the arrival of models providing 32GB for 150 euros or 64GB for 250 euros (see for example the latest OCZ model at http://www.materiel.net/ctl/Disques_hybrides_et_SSD/), I think that it is time to think about putting a SSD in my next laptop running Linux.

A lot of questions come to my mind:

(1) What filesystem to use?

It is well known that the regular file systems (ext3, ...) were designed for spinning disk (faster accesses near the center of the disk, expensive seek time, same read and write speeds, unlimited writes per sectors).

Some filesystems such as JFFS2 and YAFFS are designed for flash based disks where the number of writes on each sector is limited. Are they suitable for SSDs? I am not so sure because unlike USB keys and memory cards, modern SSDs disk are levelling the writes in hardware (I am not totally sure about that!).

(2) If some dedicated filesystems are required then which distributions are (not) providing them?

(3) How to tune the system?

- sdparm/hdparm?

- Laptop mode? Is there a sleep mode on those drives and if so, is it worth enabling it?

- Defragmentation? (just kidding)

- fsck?

(4) Can we save money by reducing the amount of RAM?

On a typical Linux system the main advantage of having a lot of memory is to use it for caching the disk. Does that really matter with a SSD?

Swapping should be a lot faster because of the reduced seek time. However, too much swap could kill your SSD faster (and you do not necessarily want to use some of the previous GB of the SSD as swap area).

Also, less memory probably means a reduced power consumption. Is that noticeable?.

(5) What laptop to choose?

The latest SSD will probably all be SATA-II? Most laptops are still SATA-I and with a typical bandwidth of 100-120 MB/s (and increasing fast), the SSDs are not far from the THEORETICAL MAXIMUM throughput of SATA-1 (150MB/s).

Does anyone know some benchmarks of Linux laptops using an SDD.

(6) Anything worth waiting a few more month before buying a new laptop?

I read somewhere that Intel is working hard to integrate SSDs in their chipsets.

Hummm... a motherboard with an integrated 16GB SDD for the OS plus an external SDD for the data.

 

1) It isn't really known which file systems are best for SSDs because no testing has been done; I do know, however, that ReiserFS (v4) is the fastest file system that Linux can use at the moment.

2) Ubuntu, my main distribution of choice, has the option of installing on a Reiser file system

3) hdparm is mainly for hard disk power management, but what you can do is enable disk caching. Look in the hdparm.conf file for enabling an option for DMA on your sda or hda disk, depending on what type of hard drive interface you have. There are tons of other options that are commented out in that file too. Tinker with it.

Fsck is for checking the file system for errors and repairing them. It won't do anything for performance. Also, laptop-mode-tools is best left untouched unless you want your laptop behaving strangely in AC/battery mode. There aren't many performance options there.

One thing I'd recommend installing is preload (sudo apt-get install preload), a predictive caching service that uses any available RAM to store program data. Its like Superfetch.

4) I'm not sure what you mean by caching the disk. If you mean using spare RAM as a cache, then you want to get roughly 2GB for Linux. Reduce the kernel's vm. swappiness via the command line as swapping might waste your SSD. Google this for details.

 

XFS is faster than reiser IMO

 

Turns out SSDs actually increase power consumption...you might want to hold off on this for a few years ;/

 

(1) I am sure that a lot of peoples will disagree. All filesystems have pro and cons depending of the kind of file and accesses you are doing.
Also, the future of ReiserFS is a still a bit uncertain.
Finally, the fastest filesystem on a HDD may not be the fastest on a SDD where the constraints are not exactly the same.

(3) Regarding hdparm, I am wondering what features should and should not be enabled:
- Does it make sense to enable prefetching. I would say no.
- If the drive has a sleep mode to save power then what should be the timeout? The wakeup is probably very fast so I would say that a very small timeout (~5s) is probably best.

I agree that fsck has nothing to do with performance except that it can be really slow even on a not so large partition. I was thinking that maybe SSDs would be less prone to errors (I can dream) and that it could be safe to increase the delay between fscks.
Of course, that wouldn't matter if fsck was a LOT faster on a SSD due to the reduced seek time (benchmark anyone?).
If fsck was only a few seconds, it could even be interesting to move it to the shutdown phase.

I was not aware of preload. I'll try it.

 

Thank, that's what I call a hot article.

I am not sure to agree with their test settings (my laptop spend a lot more time idle than doing I/Os) but some results are interesting.

However, I have to admit that the power consumption of the MTRON in idle state is quite bad.

A very important sentence is probably "many flash devices don’t feature power saving mechanisms yet".

They don't really say anything about some OS tuning designed to save power on a HDD and that could increase it on a SSD (e.g. read-ahead, ...).

The article also does not consider that any gain in time (for example, at boot or when starting applications) can be directly translated into a gain in battery life.

Anyways, I do not think that a slight increase in power consumption will prevent me from by buying a SSD. After all, as they say on the first page, "Flash is cool"

 

ReiserFS is purportedly the fastest all-around file system for Linux. It would be the best one to try out first for your SSD. The drawback is that it is still experimental; however many people use it regardless.

SSDs don't have sleep modes, in fact their power management sucks; they are either transferring or idling.

 

What I understood from several sources this evening is that sleep modes in SSDs are technically possible but usually not or badly implemented because the manufacturers are primarily focusing on speed, MTF, cost and time to market.

This is probably going to change with the arrival of big players with more experience in power savings such as INTEL.

 

I agree with srunni's overall position that it's still too early for really good SSD support in Linux, or in any other OS for that matter. The entire data storage ecosystem needs to first design and then build technologies to directly support SSDs, not utilize them with some "psuedo HDD" layer. At least if you really want to take advantage of the technology.

In Linux there's promising work going on for SSDs in the filesystem area, like LogFS, and unlike the FLASH designed file systems like JFFS2 or YAFFS. So it's best to wait, unless you like tinkering, or you want to help in development efforts. BTW, from the wiki page;

It's not something you would use for SATA drives, (or SSDs emulating SATA drives), although sdparm provides some of hdparm's functionality for SATA drives. Unfortunately it's mostly for information gathering from the drive and not for setting drive parameters.

BTW, I use XFS everywhere, including my two laptops, and my NFS server.

Good Luck..

 

Jas, hdparm was installed by default on my Ubuntu 8.04....do I leave it, and install sdparm? or not worth anything.

 

So it looks like after a bit of googling, (sorry I should have done this before posting my last response), I was in error. When I first tried to use hdparm on my first SATA laptop Linux install, it wouldn't work at all, so I installed sdparm only to find out that it basically provided drive information, but no real configuration capability, (that may have changed by now as well). I was specifically using hdparm, (or sdparm), to try and set the "use DMA" (-d) flag on my optical drive and after I found out I couldn't, or more specifically didn't need to set it, I left hdparm alone.

It appears that hdparm CAN work for SATA drives, and can set some, though not all, drive parameters like it does for IDE drives. Here's the relevant bits from the hdparm freshmeat.net project details, mailing list;

So you should keep hdparm, and if you're feeling particularly brave, try fooling around with some of the drive settings mentioned. You can also alternately install sdparm and follow the home page documentation and see if it's useful as well.

However, I'm quickly coming to the conclusion that if I need to tweak the OS, for hardware specific stuff like HDD tweaking to gain some performance here, or stuff like undervolting the CPU to save some battery there, I'm avoiding it. The tweaks can be complicated and chances are I'll forget them when I reinstall or when I install on a new machine. So I'm tending to stick to things like using the "on demand" CPU frequency scaling kernel support, and counting on whatever HDD support for performance or power savings are enabled by default, as opposed to tweaking things manually. I guess that's why I wouldn't invest a lot of time in trying to tweak Linux to support new things like SSD drives, as opposed to waiting until the support for them is more mainstream. To each their own of course..

Good Luck..