Recommend file system for SSD
 

I'll shortly be building myself a new desktop machine and intend using a SSD for the / partition. I recall reading sometime ago that it wasn't a good idea to use journalling filesystems on SSDs as it could cause premature failure with the constant reading and writing.

Now that SSDs have become mainstream, I assume this problem has been overcome? My preference would be to use Ext4, as I do on ordinary drives. Is this a good idea?

TIA,

--
Pete

IMO, ext4 is not to be used with SSD. This filesystem utilize the drive hardly. Possibly f2fs is better?

If you want top performance, use jfs, and for god's sake change the cfq scheduler
to either deadline or noop for the drive.
The problem with non journalling file systems is that the ones I know of
don't have trim support, which in the long rung might reduce performance.
As for wear from the journal I would'nt be too bothered; If the tests they
run is anything to go by, you could'nt wear it down in five years even
if you tried.

First of all :

Newer SSDs don't wear out like the early one.

Just slap some EXT4 on it.

Add some extra parameters in your fstab like theses (theses are my values for a Intel 530 SSD for example) : noatime,discard,commit=300

The first two parameters are safe for pretty much all SSDs.

Do this on each EXT4 partition you have.

noatime : disables last access data write

discard : enable TRIM on your SSD

commit = XXX : changes the delay between each data and metadata synchronizations. (Really optional, see below)

Use a custom commit value only if you have a laptop with a reliable battery or a desktop with a APC power box (or equivalent) as delaying sync is prone to data loss if you lose power.

Also, like rogan said : change your scheduler.

Why? Quite a few different sources say ext4 is one of the better choices. I'm not saying it's the best, and with the constant kernel updates with updated filesystems, they may be out of date for performance figures, but ext4 is a good filesystem choice on linux. Btrfs was also well tested pretty consistently. There are a lot of other systems out there, but most sites seem to recommend ext4 or btrfs.

And I agree that changing the default cfq (completely fair queuing) scheduler to deadline or noop is a good idea with SSDs. The cfq scheduler is designed to take into account seek times with platter spin. Deadline and noop are a much better choice, with the latter generally being more recommended because it strictly operates in a fifo (first in first out) order. However, deadline does do some prioritizations including making read requests a higher priority than write requests. This generally still allows you to have decent performance when heavy data writing is occurring, but this causes other operations that are writing to possibly lag. It's up to you, and you're welcome to try both.

Personally, I use ext4, because it's mature and well-supported. I also enabled journals and have swap on my drive (although, swap itself is rarely used). As rogan stated, the likelihood of you wearing out an ssd drive is not very likely. In a tech report article they go through and thoroughly test SSDs in how limited they are in their writes. In their very first update, they wrote that the drives had all succeeded in transferring 22TB (that is writing the data, verifying the data with MD5, and then wiping the data). That's equivalent to 20GB of data written to the drive every day for 3 years! The reason they chose this number to stop at is this is the endurance specification of Intel drives in the 335 series. The first drive failures didn't occur until over 700TB of writes! That's over 30x the specification provided by Intel, and that's the equivalent of writing over 380GB to the drives every day for 5 years! Last I checked, there are two still going that have surpassed the 1.5PB mark.

Change IO scheduler for SSD disk.
where X is you SSD.

I have to push btrfs. Snapshots are so great I could never go back to living without them. btrfs has trim support, and the ability grow the filesystem easily onto additional disks added in the future.

Benchmark:
http://www.phoronix.com/scan.php?pag...38_large&num=1

Remember to enable TRIM support in the kernel to avoid excessive wear.

Another thing for SSD performance, add discard to the fstab mount
http://techgage.com/article/enabling...t_under_linux/

Consumer grade SSDs have a highly sophisticated firmware, which is optimized for dealing with NTFS, which is a block-based file system which uses 4K allocation units. Ext2/3/4 is a block-based filesystem, too, using the same allocation size, so on the low level it is similar enough. Alignment is important, but there are no options other than "discard" really needed. "Noatime" gives a slight performance boost on spinning disks, but isn't needed on SSDs.

I would not recommend experimenting with enterprise filesystems like Btrfs or ZFS on consumer SSDs.

ZFS has good SSD support, but yes, it's not recommended.

JFS honestly is the best supportive file system on Linux for SSD drives.

Thank you all for your excellent feedback! Some really useful information in there!

I was interested to see that BassMadrigal puts the swap file in the SSD, as I would have expected this to be the biggest "no-no". I'll be using a 128GB SSD for / and a 2TB conventional disk for everything else. I could probably get away with as little as 20GB for /, but was planning to split the disk in half to allow for expansion, but also to provide space for a possible dual boot in future. It will have 16GB of ram, so I'm assuming that the swap won't get used much and perhaps putting it on the SSD as well may be acceptable?

Thanks for the pointers on trim and cfq. I would not have known about these without this feedback! From the above, I gather that cfq should only be changed for the SSD, which would make StreamThreader's post the best way of implementing this. I'm assuming that this would have to be done on each reboot, and so would have to be added to rc.local or similar.

This system isn't going to be used for gaming, but I do a lot of video processing - much of it HD - and I'm trying to speed up editing / coding / decoding times. My existing desktop is getting a little long in the tooth!

Again, many thanks for the excellent advice!

--
Pete

The best choice is to use /(root) with the SSD since it's rarely updated and put /usr, /home, /run, and /var on the standard drive. Swap actually should never be on an SSD. Swap belongs on an HDD or a skipped provided you have 8+GB of RAM.

Thanks for the clarification! That's pretty much what I had assumed, but was a bit surprised by the earlier post putting swap on the SSD.

Cheers,

--
Pete

I disagree. You don't buy a fast SSD to not get its advantages. So I recommend to put everything on it that benefits from fast read and write access, especially /usr for speeding up boot and application starting times and /home, if you do a lot of your editing/encoding stuff there. You don't want a fast CPU be slowed down by waiting for a slow mechanical disk. Also, when it comes to swap, if you ever hit swap you want swap access to be as fast as possible. There is no point in putting it on a slow mechanical disk when a much faster SSD is available.
The problem with modern SSDs is no longer wearout, but simply the available space, since getting large SSDs is still quite expensive.
So I recommend to determine what should be on the SSD and what not rather by size and if the data benefits from speed improvements.
For example, a large music library should go to a mechamical disk, since hearing music will not benefit from having a faster storage system and it will just take space on a SSD that can be used for better things.
Different example: your download directory. Downloads will be capped by your network speed anyways, so there is no point in using a fast storage device for it.

In short: make the decision what you put on the SSD based on your usage, not some arbitrary points in the filesystem.

I personally have my complete system, including /home and swap, on the SSD, with symlinks in my /home for things like downloads, music and other data pointing to directories on my mechanical disk (mounted as /data).