LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-23-2014, 12:11 PM   #1
pchristy
Member
 
Registered: Oct 2012
Location: UK
Distribution: Slackware
Posts: 425

Rep: Reputation: Disabled
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
 
Old 11-23-2014, 12:54 PM   #2
yars
Member
 
Registered: Apr 2012
Location: Russia
Distribution: Slackware64-current
Posts: 242

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

Last edited by yars; 11-23-2014 at 12:58 PM.
 
Old 11-23-2014, 01:05 PM   #3
rogan
Member
 
Registered: Aug 2004
Distribution: Slackware
Posts: 162

Rep: Reputation: 65
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.
 
Old 11-23-2014, 02:16 PM   #4
Nh3xus
Member
 
Registered: Jan 2013
Location: France
Distribution: Slackware 14.1 32 bits
Posts: 211

Rep: Reputation: 56
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.
 
6 members found this post helpful.
Old 11-23-2014, 02:16 PM   #5
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,185

Rep: Reputation: 3924Reputation: 3924Reputation: 3924Reputation: 3924Reputation: 3924Reputation: 3924Reputation: 3924Reputation: 3924Reputation: 3924Reputation: 3924Reputation: 3924
Quote:
Originally Posted by yars View Post
IMO, ext4 is not to be used with SSD.
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.

Last edited by bassmadrigal; 11-23-2014 at 02:18 PM.
 
5 members found this post helpful.
Old 11-23-2014, 02:45 PM   #6
StreamThreader
Member
 
Registered: Mar 2012
Location: Ukraine/Odesa
Distribution: Slackware
Posts: 132

Rep: Reputation: 13
Change IO scheduler for SSD disk.
Quote:
echo noop > /sys/block/sdX/queue/scheduler
where X is you SSD.
 
3 members found this post helpful.
Old 11-23-2014, 05:37 PM   #7
chemfire
Member
 
Registered: Sep 2012
Posts: 232

Rep: Reputation: Disabled
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.
 
Old 11-23-2014, 06:39 PM   #8
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

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

Remember to enable TRIM support in the kernel to avoid excessive wear.
 
Old 11-23-2014, 06:59 PM   #9
coralfang
Member
 
Registered: Nov 2010
Location: Bristol, UK
Distribution: Slackware, FreeBSD
Posts: 762
Blog Entries: 3

Rep: Reputation: 246Reputation: 246Reputation: 246
Another thing for SSD performance, add discard to the fstab mount
http://techgage.com/article/enabling...t_under_linux/
 
Old 11-23-2014, 07:39 PM   #10
jtsn
Member
 
Registered: Sep 2011
Posts: 922

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
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.

Last edited by jtsn; 11-24-2014 at 02:21 PM.
 
Old 11-23-2014, 07:50 PM   #11
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
ZFS has good SSD support, but yes, it's not recommended.

JFS honestly is the best supportive file system on Linux for SSD drives.
 
Old 11-24-2014, 03:31 AM   #12
pchristy
Member
 
Registered: Oct 2012
Location: UK
Distribution: Slackware
Posts: 425

Original Poster
Rep: Reputation: Disabled
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
Quote:
echo noop > /sys/block/sdX/queue/scheduler
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
 
Old 11-24-2014, 05:06 AM   #13
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
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.
 
1 members found this post helpful.
Old 11-24-2014, 05:47 AM   #14
pchristy
Member
 
Registered: Oct 2012
Location: UK
Distribution: Slackware
Posts: 425

Original Poster
Rep: Reputation: Disabled
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
 
Old 11-24-2014, 06:25 AM   #15
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864
Quote:
Originally Posted by ReaperX7 View Post
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.
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).

Last edited by TobiSGD; 11-24-2014 at 06:30 AM.
 
4 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: JFS File-System Can Now Handle SSD TRIM Discard LXer Syndicated Linux News 4 10-04-2012 06:23 PM
Best file system on an SSD? FiftyOneFifty Linux - Desktop 5 02-12-2012 03:29 PM
SSD File System Partitioning jaycee4 Linux - Newbie 7 09-18-2009 03:48 AM
LXer: File-System Benchmarks On The Intel X25-E SSD LXer Syndicated Linux News 0 03-16-2009 08:20 AM
FTL and file system to be used for Solid State Device(SSD) AbhijitK Linux - Embedded & Single-board computer 1 01-17-2009 09:01 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 06:39 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration