What to keep in mind with solid state disks and linux?

[RealBluescreen]

I want to install the main files of a gentoo system on a small solid state disk (MLC, 16GB) (plus a raid array with 2 hard drives).
I to check on the internet about ssds and linux, filesystems, trim options and schedulers. But the information was often very old or contradictory.

So I wanted to ask you, to what I have to pay attention, and which assertions are true:

1. You should not place /tmp and /var/tmp (or even /var) on the ssd.
   
2. Don't make partitions over the whole ssd, let one (or a few) gigabyte(s) of your ssd remain without a partition, to use these blocks if other storage cells stop working.
   
3. You got to use TRIM options.
   
4. You got to use discard option on an ext4-filesystem.
   
5. You have to choose your scheduler wisely, because the wrong decision will result in a slow system.
   
6. You should disable journaling features.

Should I run a badblocks on the brand new ssd?

Which reliable and stable filesystem would you recommend for the ssd today?
ext4, btrfs, or something else? Is there a filesystem with special features for ssds, or a stable filesystem with compression features (not reiser4)?

(I know that these questions where asked before, but they where asked a long time before - and i expect that the most answers of 2008 aren't true today, the article in gentoo wiki is also not very useful)
_________________
Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- und Meinungsforschung (§ 28 Absatz 3 und 4 Bundesdatenschutzgesetz).

[feystorm]

1. You should not place /tmp and /var/tmp (or even /var) on the ssd.
Somewhat false. While it is true that frequent writes can decrease the life of the drive, /var is not frequently written to (/var/tmp maybe a bit). There are lots of things in /var which can gain a very significant performance boost from ssd (/var/lib/mysql is one that comes to mind).

2. Don't make partitions over the whole ssd, let one (or a few) gigabyte(s) of your ssd remain without a partition, to use these blocks if other storage cells stop working.
Completely false. SSD drives include wear leveling so if cells stop working, it'll use backup cells to replace them. These backup cells arent even visible to the computer, it is done transparently by the drive itself. Holding unpartitioned areas just wastes space (the SSD will not use it).

3. You got to use TRIM options.
4. You got to use discard option on an ext4-filesystem.
5. You have to choose your scheduler wisely, because the wrong decision will result in a slow system.
Cant comment on these few options as I havent played with them much.

6. You should disable journaling features.
This is also a myth. I'm guessing this advice came around because the journal frequently changes, so youre doing a lot of writes to the drive. However not every journaling change gets written to the disk. Just like not every write is written to the disk. Thats what sync() is for. However it is true that for every disk write (non-journal data), there will be a journal write. So IO does increase, but in my own humble opinion, not enough to warrant disabling the journal. If youre really paranoid, you can store the journal on another device.


All this also depends on the type of SSD youre using (SLC vs MLC). But even with MLC which has a shorter life span, unless youre thrashing your disk with TONS of IO, you will likely never see any issues (modern SSDs have lots of internal stuff to prolong their life).

[luscinius]

Can I ask a similar question: which parts of the filesystem are better to put on an SSD to have a performance improvement: /usr? /usr/bin? /var?
Does it speed up the programs' startup time?
Thanks

[gentoo_ram]

How much RAM do you have? If you have lots of RAM and your machine stays up, then eventually most stuff will get put into disk cache in RAM anyway. So I'm not sure getting a SSD would help much. If you don't have lots of RAM, then maybe it would help. That's why I load up my personal Linux server with lots of RAM. Speeds up I/O (since you don't have to do any).

[Hypnos]

The only things I bother to do with my SSD:

1) I format the whole disk without partitions and with stripe width 32, so the filesystem is aligned as described by Ted Tso

2) Put /tmp and /var/tmp/paludis (the Paludis build directory) in RAM. I'm not sure either of this is necessary; certainly the former seems unnecessary, because my home directory has more writes than /tmp does. It might make sense on a high-volume multiuser system.

TRIM would be nice, but my Samsung disk needs a firmware update to enable it. In 1 year of continuous usage I have not perceived in performance loss, despite writing and deleting many multi-gigabyte files.
_________________
Personal overlay | Simple backup scheme

[tclover]

Naturally, you have to put your home on another PV or LV (pysical or logical volume)... but even that, it may not be necessary if you use...

Well, first of, usr:{,s}bin:lib{32,64} will benefit from random access. You can improve greatly from launching applications and starting your machine.
Now you can even got a fsater and much more responsive machine with aufs[2]+squashfs combo, this way, you can "squashed" usr:{,s}bin:lib{32,64}:opt:var/db:var/cache/edb:var/portage:var/local:portae or something similar. Further more in doing so, your usual setup with a roughly 10GB usr will only take 2~3GB of space of your SSD! You can even still have your whole or some part of your home on it! Just take care of those heavy write/reading applications and move the necessary directories. With aufs+squashfs most of the squashed directories will be in RAM. And if you have more than 2GB you'll end up with a really fast machine! Actually some part of the squashed directories are placed in RAM, which will result on using your RAM rather than leaving your ram empty, however the whole squashed directories won't be placed on RAM when you boot once it's necessary some block of squashed image will. You will benefit from reading on your SSD from that solution because most of small reading will be minimized/eliminated... writing will not benefit much as every writing will go to your drive directly. See here or over there for more info.
For further tunning, you could of course place your firefox profile in RAM as well see this thread for info, because firefox will wear your drive otherwise!
And you can put some of var on RAM as well like log and /var/tmp/portage, see here for more info. It coulf be difficult for var/tmp/portage if you heven't plenty of RAM, you can just put it anywhere because that directory may be big depending on what you're building... log doesn't take any significant space, so you can put it ram if you want.
That's all. You can possibly build a very very fast system with SSD+AUFS+SQUASHFS+TMPFS!

[graysky]

https://wiki.archlinux.org/index.php/Solid_State_Drives

[chiefbag]

I wonder about all the hype and hot air that has been bantered around about ssds.
There are a couple of facts which exist that contribute to the reason why they operate the way they do and why they are so fast over standard mech. drives.


1: They have no physical moving parts.
2: They consume less power.
3: They are multiple times faster then standard mech drives for reads and writes.


-- Myth

Some say you should not expose your drive to intensive I/O ie. compiling as this can degrade the drive more quickly, there is little evidence to support this.
The notion of partitions and file structure are what fat32 is to ext2.
In actual fact what makes a great ssd over a good one is the firmware and controller in the ssd which no O/S has any control over.
Wear leveling on a firmware/controller will take care of any concerns you may have.

-- Fact

I reckon by the time you have burnt out your ssd you will have probably throwen it away at least 2 years prior.

Thats just my 10 cent

[Hypnos]

Well, quoting the Arch wiki page: