Mageia forum

(I hope this is the correct place to post this. It concerns SSD optimizations; but since Mageia 3 RC is using systemd, I "guessed" it was a Cauldron thing. Sorry if I "guessed" wrong.)

I'm using Mageia 3 RC and want to implement SSD optimizations described in an excellent article on the subject:
"How to maximise SSD performance with Linux"
http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm

However, to replace the scheduler "QFC" (optimized for HDD's) with "deadline" (ideal for SSD's), it's necessary to add a statement to the /etc/rc.local file which no-longer exists under systemd.
The statement is: echo deadline >/sys/block/sda/queue/scheduler

I also want to use another tip about creating a primary Swap file in RAM (my only storage device is an SSD and I have 8 MB of RAM), leaving the Swap file on the SSD to be used only when RAM is full.
The tip indicates it's necessary to add a statement to that same /etc/rc.local file:
echo 0 >/proc/sys/vm/swappiness

I read in another post that it's possible to create an rc.local file and cause it to run, but I'm hoping somebody more knowledgeable about Linux than I, can suggest a way to make the same adds in an existing file under systemd.

Many thanks for any help you can provide.

Good questions. Sorry I am no help. I have been distro surfing looking to find a distro that has automatic SSD optomization along with included codecs or an easy to use script. So far nothing is really turning up. I hope someone chimes in here. It would seem like SSD optomization would be a good tool to include in the Mageia control center. Then again, so would the ability to enable all codecs.

Fargo, you won't find simple codec solutions directly from Mageia or from most other distros for that matter because they are proprietary and IP laws are involved. The legally dubious solution is to go to the "tainted" repository where you should find audio/video apps there that include codecs to play most anything (with a few exceptions, like compressed Quicktime, etc). The legal route is to go with Fluendo (fluendo.com) and they will supply you with a broad range of fully licensed codecs (including Windows Media) for a reasonable charge in a package that will install painlessly on Mageia. I have chosen Fluendo and simply pay them on a regular bases and they supply updated codecs. I also use some stuff from the tainted repository and between the two, everything just works with EXTREMELY rare exceptions. - George

NOW - Hopefully someone can help BOTH OF YOU with the SSD optimization issue.

Funny thing about having a problem. Either you just quit and give up, or you use your Google-given rights and search for an answer; and after Google-ing around, I have it mostly solved.
I know I should have done that first before posting. Hopefully, it will be helpful to others.

To revise the IO Scheduler from the default of "CFQ" to "deadlline", just add a kernel parameter of "elevator=deadline";
and to make it permanent, modify the appropriate entries in the /boot/grub/menu.lst file to add the above kernel parameter.
One problem solved

To reduce the swappiness (to minimize the amount of swap file use on the SSD), and assuming you have a large amount of RAM,
modify the /etc/sysctl.conf file to add a line containing:
vm.swappiness=1
That way, it won't use your swap file on the SSD, unless not enough RAM is available.

The other problem solved, in theory anyway. The next step is to apply the theory and see if it works. Then I'll add [Solved] tp the Subject; but that's assuming I can boot-up again after the changes.
The article I referenced in my original post is very helpful in a person's attempt to understand what they can do to improve the longevity and performance of an SSD.

Additional comments encouraged.

Hello Larry, I *assume* you have 8GB of RAM. 8MB these days is ridiculous. In that case you can simply remove the swap partitions from your SSD and use the space for something else. Swap is really not required unless you are low on RAM. In my case I have only 4GB of RAM and I did not even create swap space when I loaded the system. Its optional, really, you can just get rid of it. Oh ... and glad you found answers on Google. Google is absolutely amazing. I have the same experience over and over. I go ask for help and then before anyone can even answer, I hit paydirt on Google. - George

There is also some info in our Wiki about SSD.

LarryDan wrote:it's necessary to add a statement to the /etc/rc.local file which no-longer exists under systemd.

It's still there, just relocated.

Comment from /lib/systemd/system/rc-local.service:

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.d/rc.local is executable.

So all you need to do is add your commands into /etc/rc.d/rc.local and make that file executable.

ghmitch: Thank you George. I agree! Linux is so damned resource-efficient that I was easily able to operate with only 1 GB of RAM before building this new one; Even with only 1 GB, it rarely used the swap file, and when it did, it was never more than a couple of hundred MB's. So in a vain attempt to "future-proof" my new one and provide other possible capabilities, I opted for 8 GB. This method will only revert to the swap file on the SSD if for some reason, 8 GB of RAM aren't enough. For example, one of the things I could do with this much RAM is to load a DVD image into memory and execute from RAM instead on an installation. However, not knowing what's just around the bend (and because the 8 GB's of DDR3-1600 were less expensive than the 1 GB of DDR I purchased a bunch of years ago), I went for it anyway, even though 2 x 1 GB would have been ample.
Thank you for your help.

filip: Thanks for the link to the SSD Wiki. There's a lot of good info there. I appreciate your help!

sander85: Thank you for the new location. I'm having difficulty locating the rc.local file, but that's exactly the kind of information I was hoping for. Prior to posting my request for help, using Dolphin, I searched for the rc.local file, but when I discovered that there are a bunch of RC folders (rc0.d, rc.d, and more), I didn't want to "guess" and posted my request. When I looked now in the /etc/rc.d folder, I couldn't find an rc.local file. There are many folders, and only 1 file, "rc.alsa_default". I tried the rc0.d folder, and nothing there either. Then I searched the root folder for all file names with "rc.", and then again with "local", but wasn't able to locate a file with the name of rc.local.
Also, I apologize for my lack of linux knowledge, but I don't know how to make a file executable; although I should search for the answer on that one before asking for your help.
Thank you very much for the info, and if you could help with my two remaining questions (where is rc.local, and how to make a file executable), I'd be most grateful.

What a great community this is! I posted a request for assistance, and immediately people from all over the World (California, Slovenia, and Estonia) are trying to help. Would't it be great if everyone was as eager to help as you've been!!! Thank you very much!

If the file doesn't exist you just have to create it

This is the easy way to solve your problem (enter these commands as root (to become root, use command su)):
echo "echo deadline >/sys/block/sda/queue/scheduler" > /etc/rc.d/rc.local
echo "echo 5 >/proc/sys/vm/swappiness" >> /etc/rc.d/rc.local
chmod +x /etc/rc.d/rc.local

The first line will add your first command into /etc/rc.d/rc.local.
The second line will add your second command in the end of /etc/rc.d/rc.local (> will overwrite whole file (or will create it if there is none), >> will add your content in the end of file).
And the third line will make that file executable (you can read more about the chmod here: http://www.linux.org/article/view/file- ... ions-chmod)

Great! Thank you. That's exactly what I needed. I can now close this one as [solved]. However, I have just a few more items that I'm trying to resolve/decide connected to this subject.

You'll probably laugh, but I've been using Kwrite as my editor on system files (kdesu kwrite). It does the job; although now, I can see the benefit of using echo instead.

I've spent the last several days becoming more knowledgeable about SSD's (this is my first) and about Linux commands, and it's been greatly helped by people such as you who are willing to answer requests for assistance. I don't want to monopolize your time, but here are a few more thoughts/concerns about items that I'm not sure of:

1. In searching for IO Scheduler choices that favor SSD's, there is a certain amount of debate as to whether NOOP or deadline is better, and I'm going with deadline, which seems to be slightly favored over NOOP. That it prioritizes reading over writing is a good thing, and I'm willing to sacrifice a little overall performance for that ability. NOOP is just a FIFO scheduler.

2. I noticed you recommended a swappiness of 5. I've seen quite a few recommendations of either 0 or 1. I realize that any number under 10 would be adequate, and I'm inclined to go with 1, only because it seems to be the number recommended the most. Feel free to debate that if you want to.

3. In terms of reducing the amount of swap, it was also recommended to revise the vm.vfs_cache_pressure from the default of 100 to 50; but I read several articles by people who tested the results of using various numbers, and one in particular claimed that with a swappiness of 1 and a cache_pressure of the default 100, he experienced the best performance and fewest swaps. So that seemed like the way to go.

4. Prior to reading your latest reply, I had planned on making the swappiness revision by doing a kdesu kwrite on the /etc/sysctl.conf file. Would that work as well, or do you recommend I create the rc.local file as the better way?

5. This one is the most debatable: There are many Web articles that discuss replacing relatime with noatime and nodiratime for drive mounts (sda1, tempfs, and etc.). After doing the research, I now understand how noatime works. While there is a distinct performance advantage to using noatime and not re-writing access date-times on reads, it will eventually produce a last access time earlier than the last modified time. For tmpfs files, it might not be significant; but I was planning on moving from Evolution to KMail for my e-mail, and I know it will play havoc there, and it could possibly confuse other programs that rely on last access times. I could go noatime on tmpfs files only and leave the relatime for everything on my sda1 (/) and sda5 (/home) SSD partitions. You care to venture an opinion on that one?

Many thanks again for all your help.

LarryDan wrote:You'll probably laugh, but I've been using Kwrite as my editor on system files (kdesu kwrite). It does the job; although now, I can see the benefit of using echo instead.

Instead of echo I would suggest you to learn vim or some similar command line editor. Or just use mc which has editing option as well.

LarryDan wrote:1. In searching for IO Scheduler choices that favor SSD's, there is a certain amount of debate as to whether NOOP or deadline is better, and I'm going with deadline, which seems to be slightly favored over NOOP. That it prioritizes reading over writing is a good thing, and I'm willing to sacrifice a little overall performance for that ability. NOOP is just a FIFO scheduler.

I'm using deadline on all my SSDs and have had no problems so long.

LarryDan wrote:2. I noticed you recommended a swappiness of 5.

This is what I use myself, but I'm quite sure that any value below 10 is OK.

LarryDan wrote:3. In terms of reducing the amount of swap, it was also recommended to revise the vm.vfs_cache_pressure from the default of 100 to 50; but I read several articles by people who tested the results of using various numbers, and one in particular claimed that with a swappiness of 1 and a cache_pressure of the default 100, he experienced the best performance and fewest swaps. So that seemed like the way to go.

I haven't played with that option myself so I can't comment here

LarryDan wrote:4. Prior to reading your latest reply, I had planned on making the swappiness revision by doing a kdesu kwrite on the /etc/sysctl.conf file. Would that work as well, or do you recommend I create the rc.local file as the better way?

I think it would work. Tho' there is now sysctl.d directory, maybe it's a better place. http://www.freedesktop.org/software/sys ... ctl.d.html - it doesn't mention sysctl.conf so it may be obsolete for now.

LarryDan wrote:5. This one is the most debatable: There are many Web articles that discuss replacing relatime with noatime and nodiratime for drive mounts (sda1, tempfs, and etc.). After doing the research, I now understand how noatime works. While there is a distinct performance advantage to using noatime and not re-writing access date-times on reads, it will eventually produce a last access time earlier than the last modified time. For tmpfs files, it might not be significant; but I was planning on moving from Evolution to KMail for my e-mail, and I know it will play havoc there, and it could possibly confuse other programs that rely on last access times. I could go noatime on tmpfs files only and leave the relatime for everything on my sda1 (/) and sda5 (/home) SSD partitions. You care to venture an opinion on that one?

AFAIK noatime for SSDs is suggested to save SSDs, it's not that much of a performance option. You won't notice any performance drop if you are not using it. It just avoids constant writing on SSD. I think SSDs today are more reliable than they used to be and maybe it's not a problem. I'm using noatime myself tho' and haven't noticed any problems doing so. My mail client is Thunderbird tho'. But noatime for tmpfs is non sense

Instead of echo I would suggest you to learn vim or some similar command line editor. Or just use mc which has editing option as well.

Thanks. It looks as if Vim was voted the most popular by other Linux users a few years ago. I'll certainly give it a try.

1. (re: choice of IO Schedulers) I'm using deadline on all my SSDs and have had no problems so long.

Glad to hear it's been working well for you. That's what I'll use also.

2. (re: a swappiness of 5) This is what I use myself, but I'm quite sure that any value below 10 is OK.

I think I'll go with a swappiness of 1 and evaluate (if I can) how effective it is; although 5 or 1 will probably be just as effective.

3. (re: vm.vfs_cache_pressure) I haven't played with that option myself so I can't comment here

I'm going to leave it at the default of 100.

4. (re: revising swappiness via the /etc/sysctl.conf file) I think it would work. Tho' there is now sysctl.d directory, maybe it's a better place. http://www.freedesktop.org/software/sys ... ctl.d.html - it doesn't mention sysctl.conf so it may be obsolete for now.

Currently, I have data in my /etc/sysctl.conf file. It has 5 statements with net.ipv4.icmp parameters; however, I read the page at the link you provided, and I agree it does seem as if it might be better to do it that way.

5. (re: noatime) AFAIK noatime for SSDs is suggested to save SSDs, it's not that much of a performance option. You won't notice any performance drop if you are not using it. It just avoids constant writing on SSD. I think SSDs today are more reliable than they used to be and maybe it's not a problem. I'm using noatime myself tho' and haven't noticed any problems doing so. My mail client is Thunderbird tho'. But noatime for tmpfs is non sense

Yes, I should have been more careful about using the word "performance" (increase). I know; noatime is just for the purpose of reducing the number of writes to help preserve the longevity of the SSD, and doesn't have much of an impact on performance; and it makes absolutely no sense to include noatime when the writes are to RAM with tempfs files.
I'm still undecided whether using noatime on my SSD partitions will cause any logic problems in application or utility programs; but there's only one way to found out if it will.
So it sounds as if I've made up my mind to use noatime and see what happens. After all, it's only a home computer, and I'm not running a corporation's finances on it.

BTW, as I mentioned, this is my first experience using an SSD, and like you, I chose the Kingston HyperX 3K. It's been working like a champ. I'm really glad I made that choice.
Again, thanks for all of your help and for being so prompt with your replies. It's greatly appreciated!

All the best to you sander85 and thanks to everybody else who replied. I can call this one [SOLVED] now.

Great you got this one solved LarryDan.

Now, will you please be so kind marking the topic accordingly?

You can do so, by editing the subject/title in the first message of this topic.
Place [SOLVED] in front of the subject/title, and that will do.

Thank you!!!

Ahem, you were faster than i replied.

Thanks anyway!!!