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).

pchristy,

You can take a look at the corresponding section of Arch Linux wiki. What I did couple of years ago was to stick to EXT4, modifying my /etc/fstab like this for /:

/dev/sda1 / ext4 defaults,noatime,discard 0 1

So far I have not had any issues, but I would appreciate if someone with more knowledge confirms that this setup is fine.

I totally agree with TobiSGD. Modern SSDs are not nearly as prone to wearing out the drives as the older ones. That was the whole point in me mentioning that tech report article. With the way wear leveling works and the advances in technology to increase the actual write limitations, you'd have to go through an astronomical amount of data to actually wear the drive out. And when I say astronomical, Intel's spec is rated for 20GB written to the drive, EVERY DAY, for THREE YEARS!! Who does that? And that's just what it's rated for. The tests showed that it was actually capable of 30x that amount before the drive actually failed. They were able to write over 700TB to the drive before it broke. I did the math and that's the equivalent of 380GB written to the drive, EVERY DAY, for FIVE YEARS! Depending on the size of your drive, that could literally be wiping the drive every day and copying everything back over for 5 years. (2 drives have over 1.5PB written and were still going on the last update -- I don't think I need to do the math there ;) ) Basically, with modern SSDs, you will almost always have the hardware fail before you no run out of writes.

So no, I'm not worried about putting swap on the SSD. As TobiSGD mentioned, when you start using swap, it's because your extremely fast RAM filled up. Why not use the next fastest available media if you're not worried about it dying? I actually have a very basic partition layout. I have swap, /, and /home on my SSD and all my media is stored on the other 5 traditional hard drives. I don't worry about moving /tmp over, because /tmp is the place a lot of software is compiled by slackbuilds. I want that fast. I supposed I could move /tmp to RAM for an increase in speed, but I only have 8GB on my system (maxed out -- system is almost 7 years old) and I tend to max out my RAM pretty consistently already. I can definitely see the reasoning behind TobiSDG's linking of mostly static home content to other drives, but that's just too much effort and would mess with my folder structure on my media drives. But from a logical standpoint, it does make sense to move things you wouldn't normally access to a traditional drive. I would, without a doubt, at least include /usr for the same reasons TobiSDG mentioned. You want the applications you open to benefit from that increased speed you have available.

Anyway, I'm about ready to get off my soapbox. The only other thing I can recommend is considering switching from noop to deadline. Both are immensely better than cfq, however, I personally believe deadline is a better option if you're not running a production server. The reason behind this is it queues all the requests and will give preference towards reads over writes, so it will generally leave your system more responsive if you're doing some intense hard drive activity. Either way, using the command you listed, you can easily try out the two and see if you find one more to your liking.

Once you're ready to make it permanent, I know it's possible through lilo/grub, but it makes the change for all drives connected to the system. You can do that with a simple append line to your lilo.conf.

You can also play around with the udev rules and have it set there, but I haven't tinkered with this much. This should set any non-rotating drive to deadline, but I am not sure how this would fare with removable flash media like thumbdrives and memory cards. However, I'd guess any issues would be minimal.

You can just add this to a file you create in /etc/udev/rules.d/ and you can call it something like 55-ssd.rules and then reboot. Verify it was set properly via cat /sys/block/sda/queue/scheduler

Anyway, I think I've said enough for now :)

It's far better to use deadline if it's going to be a kernel parameter
changing it to a default for all drives in the system.
The tests I've done with bonnie++ on platter drives and ssd's, all
with jfs, show that as far as performance concerns you really should not
use cfq for anything. The performance hit with cfq is in the order of ten-fold
under some circumstances.

Here are two examples on a aic7xxx controller with a fujitsu map 10krpm 36GB scsi drive:

cfq on generic 3.10.17 smp kernel:
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
1G 9902 98 46816 58 18580 24 11293 98 65370 32 381.8 5
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
10 105 11 +++++ +++ 124 0 107 10 +++++ +++ 124 4

deadline on generic 3.10.17 smp kernel:
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seek--
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
1G 9947 98 53247 59 25271 31 11355 98 66862 32 410.7 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
10 481 39 +++++ +++ 1277 23 559 47 +++++ +++ 997 35

The difference in performance when it comes to many small files as is the case on e.g. a mail server is ten-fold in this case.
If you want to see how jfs performs compared to other file systems on a modern linux kernel on ssd's:
http://www.phoronix.com/scan.php?pag...ux317_fs&num=1
The editor claims that jfs delays journal writes and thus "cheats".
I tend to think that if it was good enough for IBM mainframes it's
good enough for a speed freak like me.

Seeing that, it seems that JFS is really only the best when it can queue the writes. On the other tasks, it seemed to lag behind many other contenders. Overall, I still don't think there is a clear winner on the best filesystem for SSDs. JFS can be extremely fast in some scenarios, but it didn't do nearly as well in the compile benchmarks.

Make sure to use deadline I/O scheduler with JFS, as this works best.

Scheduler choice is probably more hardware and application dependent than file system dependent.
I have seen cfq do pretty well on older low-spec hardware even with jfs if you don't run database loads.

Some thougts about SSD.

1. Better buy UPS or SSD with power loss capasitors.

http://lkcl.net/reports/ssd_analysis.html

2.If you "discard" /TRIM enabled/ the good is longer endurance the bad is after "TRIM" the data are unrecoverable .

3.if trim on lvm backend remember to set "issue_discards" option in /etc/lvm/lvm.conf .

4.There is some security issue in wiping data from SSD neither ATA "secure erase" nor fill entire disk with 0 do not give 100% of sure.
eg.
http://nvsl.ucsd.edu/index.php?path=projects/sanitize
https://www.google.pl/url?sa=t&rct=j...80185997,d.cWc

5. If You encrypt disk with LUKS better move "luks header" to HDD to avoid incidental demage caused by garbage collection of the disc .
Of caurse you can switch "discard" on device mapper It helps, but no one knows how each manufacturer's firmware behaves in this case. There is no standard.

6. If you encrypt disc with trim enabled , another issue. Better not trim :-)

http://asalor.blogspot.hu/2011/08/tr...-problems.html

If that do not bother anybody You can enjoy the system is booted in 10-15 seconds.
You have to move forward :-)

Why should GC cause any damage to user data?

Actually ATA TRIM is standardized very well.

Sory for my english. I mean "demage" that part of partition containing luks header and slots in the sense copy of part or all of a completely different place and unpredictable. For encrypted device in terms of security is "demage" IMO.

SSD controllers internally re-route the write location of the ATA commands for disk leveling purposes. One side effect of this is you could end up with two (or more) copies of your LUKS header on the drive. On a regular HDD, if one passphrase gets compromised, you can just use LUKS to revoke that key and create a new one (as long as the master private key wasn't compromised in the process.) On an SSD if you do this, an you could potentially find an old copy of your LUKS header and use the compromised passphrase to gain access to your entire drive, even data that was written after the change (because you're still using the same master private key until you reformat.)

and

http://code.google.com/p/cryptsetup/...AskedQuestions
Section
5.19 What about SSDs, Flash and Hybrid Drives?

Prior to the SATA 3.1 spec introduced in July, 2011, the Trim command was not queue-able, and could result in severe performance degradation if issued after every filesystem delete operation. Unless you have newer devices and drivers that support the queued Trim command, you are better off running a daily cron job that runs an fstrim command.

You can run to see if your drive supports SATA Rev 3.1.

But only one of them will be accessible over SATA with read commands.
No, you can't. Because the SSD won't give you access to the overwritten LUKS header.

I use JFS with discard, no problems whatsoever. I still would prefer to use F2FS but that hasn't been an option yet, hopefully that will change in the not-too-distant future since that is a filesystem designed FOR such disks. :jawa:

For maximum SSD performance, you want something with the least possible CPU load.

I prefer ext4 on my SSD's and on my root filesystems, and XFS on non-root filesystems on spinning drives.

XFS really shines when directory sizes become very large (tens of thousands or hundreds of thousands of files), and when accessing deeply-nested hierarchies of subdirectories. I use it for bulk data storage filesystems.

Ext4 has better SSD support, and is measurably faster at accessing small files in typically-sized directories (as seen on root filesystems). Multi-process locking/unlocking of lockfiles, in particular, is about 25% faster (on my hardware, under Slackware 14.1) under ext4 than XFS.

On the other hand, if I think I'll want to use XFS's administrative tools (particularly xfsdump, xfsrestore, and xfs_freeze), I'll use XFS even if it's on an SSD and/or root filesystem. They're only really worth it in my experience on systems with a lot of shell users, or webmasters, each with their own /home directories.

How come ? Either way JFS has the lowest, I'm just wondering why.

Modern SSDs are so fast, that throughput will also be limited by the host CPU.

Interesting, that may actually be why JFS is so fast, it has very low CPU usage. I didn't know this was why.

This seems way off. I have nothing to back it up other than just knowing RAM and SATA III speeds (maybe there's something else occuring that I'm not aware of... is it CPU intensive to write to an SSD? That doesn't seem right...), but the interface between RAM and the CPU is much faster than the interface between the CPU and the SSDs. I think you're still limited by the flash hardware itself, and then the interface (SATA III). DDR3-1333 has a max bandwidth of 10.6 GBps, and DDR3-1866 maxes out at 14.9 GBps (source). SATA III has a max theoretical limit of 6.0 Gbps, but real world limits of 600MBps. I'd be surprised if you move the needle much on your CPU usage when transferring files from one SSD to another (I can't test since I only have one SSD).

I recently replaced my Thinkpad's 5400RPM HDD with Kingston SSD(UV100 120GB). I simply used ext4 for / and /home with noatime plus discard options. I even have swap on SSD, I don't care if it's good or not to have it on SSD.

The system is now fluid like smoke from Bob's Cigar. Much smoothness, much like.

Regards.

First of all, a big thank you to all who contributed to this thread. I am not a programmer - just a reasonably experienced Slacker - but I've learned a lot from just following this through!

My new machine is now up and running - I'm typing this on it! I went for Ext4 (because I've been using it a while without issues) and put both / and swap on the SSD. I figured with 16GB of ram, the swap shouldn't get used much anyway! I also added noatime and discard to the / fstab entry and switched to the deadline scheduler. All I can say is wow! This machine is like greased lightning compared to the one it replaced!

I've taken the bull by the horns and installed slack64-current (should make upgrading to the next stable release easier!) and UEFI. The UEFI install didn't go completely to plan due to my inexperience with it, but I know Slack well enough to work out what I'd done wrong and fix it. I'm actually quite pleased with myself for that!

The motherboard is a Gigabyte Z97X, though in contrast with my earlier machines, I've stuck with the on-board Intel graphics. I don't need 3D performance - most of my work is video - and the Intel graphics with vaapi are even faster than my previous NVidia / vdpau setup.

All in all, I'm a very happy bunny, in no small part thanks to the excellent advice given here.

Again, many thanks to all concerned!

--
Pete