[opensuse] Do I need to do anything special for SSD in Leap 42.3?
All, I was checking the opensuse articles on SSD and most are 11.2 - 11.4 timeframe, and the latest is non-official. https://en.opensuse.org/SDB:SSD_performance https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse https://lizards.opensuse.org/2015/02/06/ssd-configuration-for-opensuse/ All the prior articles discuss putting noatime in fstab, moving tmpfs to ram, disabling browser cache, and setting vm.swappiness=1. They also talk about running fstrim on each boot and putting it in boot.local. What do we do for trim? I've checked systemd trim.service and timer are disabled? Is these customization still needed on Leap 42.3 or does the setup now recognize SSD and make the needed changes? I don't swap (I have one, it's just never used - 8G of RAM). So do we need to enable fstrim service and fstimer? What says the brain-trust? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 07/04/2018 à 10:25, David C. Rankin a écrit :
What says the brain-trust?
I try to buy 3 years guaranty disks, make often backups and do nothing else (and have nearly only ssd now as root) - I mostly use ext4, but mostly because large ssd are expensive jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op zaterdag 7 april 2018 10:25:44 CEST schreef David C. Rankin:
All,
I was checking the opensuse articles on SSD and most are 11.2 - 11.4 timeframe, and the latest is non-official.
https://en.opensuse.org/SDB:SSD_performance
https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse
Forget about the above one. The guy writes openSUSE instructions without running it himself. And gives zero support if his advice turns out to be wrong.
https://lizards.opensuse.org/2015/02/06/ssd-configuration-for-opensuse/
All the prior articles discuss putting noatime in fstab, moving tmpfs to ram, disabling browser cache, and setting vm.swappiness=1. They also talk about running fstrim on each boot and putting it in boot.local.
What do we do for trim? I've checked systemd trim.service and timer are disabled?
Is these customization still needed on Leap 42.3 or does the setup now recognize SSD and make the needed changes? I don't swap (I have one, it's just never used - 8G of RAM). So do we need to enable fstrim service and fstimer?
Leave it up to the system. I've been using SSD's for years now, and I treat them no different than I treat HDDs, and trust the system to know how to optimally set things where needed.
What says the brain-trust?
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2018 05:04 AM, Knurpht @ openSUSE wrote:
Leave it up to the system. I've been using SSD's for years now, and I treat them no different than I treat HDDs, and trust the system to know how to optimally set things where needed.
That's what I finally decided. I found fstrim.timer enabled and giving me a weekly trim. That's good enough for me. Thanks for the feedback. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2018 03:28 AM, David C. Rankin wrote:
On 04/07/2018 05:04 AM, Knurpht @ openSUSE wrote:
Leave it up to the system. I've been using SSD's for years now, and I treat them no different than I treat HDDs, and trust the system to know how to optimally set things where needed.
That's what I finally decided. I found fstrim.timer enabled and giving me a weekly trim. That's good enough for me. Thanks for the feedback.
There are threads in the list archive about this very subject, posted by myself and others. Some of these cited articled by Ted Tso. Summary: Get rid of any discard settings in fstab, use systemd fstrim.timer, as you've decided already. The next generation of SSDs probably will work just fine with discard only. But current ones work better with fstrim scheduled. After massive deletes, running an extra trim manually afterwards doesn't hurt. I just did an upgrade and running an fstrim -a gets pretty busy for a while. Trimming once a week is optimal for most user's machines. Over provision your partitions. Sizing too precisely doesn't allow the drive to do wear leveling. Some recommend leaving some un-allocated space, but that's nonsense and you can just add that extra space to / or to /home if you have one, and you will get the same wear leveling functionality. As for noatime, relatime argument, keeping atimes makes sense if you can name even ONE single valid current use for atimes. If not, turn it all off and save your SSD with noatime. The BTRFS people said that BTRFS is not optimized for use with SSDs, I don't know if that has changed, but I've still got BTRFS on my 5 year ban list. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-07 10:25, David C. Rankin wrote:
All the prior articles discuss putting noatime in fstab, moving tmpfs to ram, disabling browser cache, and setting vm.swappiness=1. They also talk about running fstrim on each boot and putting it in boot.local.
noatime is not needed. relatime is the default. I would add "lazytime", and perhaps disable "noatime", but also for rotating disks.
What do we do for trim? I've checked systemd trim.service and timer are disabled?
The timer should be enabled, unless you have the option on fstab. Apparently.
Is these customization still needed on Leap 42.3 or does the setup now recognize SSD and make the needed changes? I don't swap (I have one, it's just never used - 8G of RAM). So do we need to enable fstrim service and fstimer?
What says the brain-trust?
Apparently, no customizations are needed. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 04/07/2018 06:31 AM, Carlos E. R. wrote:
On 2018-04-07 10:25, David C. Rankin wrote:
All the prior articles discuss putting noatime in fstab, moving tmpfs to ram, disabling browser cache, and setting vm.swappiness=1. They also talk about running fstrim on each boot and putting it in boot.local.
noatime is not needed. relatime is the default. I would add "lazytime", and perhaps disable "noatime", but also for rotating disks.
What do we do for trim? I've checked systemd trim.service and timer are disabled?
The timer should be enabled, unless you have the option on fstab. Apparently.
Is these customization still needed on Leap 42.3 or does the setup now recognize SSD and make the needed changes? I don't swap (I have one, it's just never used - 8G of RAM). So do we need to enable fstrim service and fstimer?
What says the brain-trust?
Apparently, no customizations are needed.
I went ahead and added a reduced swappiness setting in /etc/sysctl.d/99-sysctl.conf, e.g. vm.swappiness=1 There doesn't see to be any reason for changing the default cache_pressure from 100, as the link indicated, e.g. vm.vfs_cache_pressure=50 Reducing the rate the kernel will reclaim dentries and inodes due to memory pressure doesn't make a whole lot of sense. See: https://www.kernel.org/doc/Documentation/sysctl/vm.txt Thanks for the additional info! -- David C. Rankin, J.D.,P.E.
On April 7, 2018 8:55:47 PM PDT, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
On 04/07/2018 06:31 AM, Carlos E. R. wrote:
On 2018-04-07 10:25, David C. Rankin wrote:
All the prior articles discuss putting noatime in fstab, moving tmpfs to ram, disabling browser cache, and setting vm.swappiness=1. They also talk about running fstrim on each boot and putting it in boot.local.
noatime is not needed. relatime is the default. I would add "lazytime", and perhaps disable "noatime", but also for rotating disks.
What do we do for trim? I've checked systemd trim.service and timer are disabled?
The timer should be enabled, unless you have the option on fstab. Apparently.
Is these customization still needed on Leap 42.3 or does the setup now recognize SSD and make the needed changes? I don't swap (I have one, it's just never used - 8G of RAM). So do we need to enable fstrim service and fstimer?
What says the brain-trust?
Apparently, no customizations are needed.
I went ahead and added a reduced swappiness setting in /etc/sysctl.d/99-sysctl.conf, e.g.
vm.swappiness=1
There doesn't see to be any reason for changing the default cache_pressure from 100, as the link indicated, e.g.
vm.vfs_cache_pressure=50
Reducing the rate the kernel will reclaim dentries and inodes due to memory pressure doesn't make a whole lot of sense. See:
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
Thanks for the additional info!
With your SSD almost as fast as ram, why are you so afraid of swapping? Jack that swapiness up to 60 or more. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-08 06:33, John Andersen wrote:
On April 7, 2018 8:55:47 PM PDT, "David C. Rankin" <> wrote:
On 04/07/2018 06:31 AM, Carlos E. R. wrote:
On 2018-04-07 10:25, David C. Rankin wrote:
I went ahead and added a reduced swappiness setting in /etc/sysctl.d/99-sysctl.conf, e.g.
vm.swappiness=1
There doesn't see to be any reason for changing the default cache_pressure from 100, as the link indicated, e.g.
vm.vfs_cache_pressure=50
Reducing the rate the kernel will reclaim dentries and inodes due to memory pressure doesn't make a whole lot of sense. See:
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
Thanks for the additional info!
With your SSD almost as fast as ram, why are you so afraid of swapping?
Jack that swapiness up to 60 or more.
How can I find the actual current values? I don't have those variables at all. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 04/08/2018 04:46 AM, Carlos E. R. wrote:
On 2018-04-08 06:33, John Andersen wrote:
How can I find the actual current values? I don't have those variables at all.
From the link I provided: swappiness This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone. The default value is 60. -- David C. Rankin, J.D.,P.E.
On 2018-04-08 12:22, David C. Rankin wrote:
On 04/08/2018 04:46 AM, Carlos E. R. wrote:
On 2018-04-08 06:33, John Andersen wrote:
How can I find the actual current values? I don't have those variables at all.
From the link I provided:
swappiness
This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.
The default value is 60.
Please post a command that writes that value to the screen. I fail to see that in your link. I want to see what is the actual value in my system, not what a document says is the default. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 04/08/2018 05:28 AM, Carlos E. R. wrote:
Please post a command that writes that value to the screen. I fail to see that in your link. I want to see what is the actual value in my system, not what a document says is the default.
Oh, sorry, $ cat /proc/sys/vm/swappiness -- David C. Rankin, J.D.,P.E.
On 2018-04-08 13:12, David C. Rankin wrote:
On 04/08/2018 05:28 AM, Carlos E. R. wrote:
Please post a command that writes that value to the screen. I fail to see that in your link. I want to see what is the actual value in my system, not what a document says is the default.
Oh, sorry,
$ cat /proc/sys/vm/swappiness
Thanks :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 04/07/2018 11:33 PM, John Andersen wrote:
With your SSD almost as fast as ram, why are you so afraid of swapping?
Jack that swapiness up to 60 or more.
Never swaps anyway, so I figure dropping the affinity for swapping, just limits the aggressiveness with which the kernel would swap if it did. Using '0' sets a hard limit of when free and file-backed pages are less than the high water mark. I didn't think I needed to go that far. 60 is the default. I'll just watch it. I just opened Win7 where I allocate 2G for the OS -- still no swapping either way (still have 2G free) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-08 06:33, John Andersen wrote:
With your SSD almost as fast as ram, why are you so afraid of swapping?
Jack that swapiness up to 60 or more.
Wear of SDD perhaps ? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/04/18 12:04, suse@a-domani.nl wrote:
On 2018-04-08 06:33, John Andersen wrote:
With your SSD almost as fast as ram, why are you so afraid of swapping?
Jack that swapiness up to 60 or more.
Wear of SDD perhaps ?
In reality, you'll probably find your drive is obsolete before it's worn out. cf that test that absolutely hammered a bunch of SSD drives and I think it took a year and more of almost continuous writes, rewrites and scrubs 24/7/365 before even the first drive failed. Most survived a LOT longer. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/09/2018 12:13 PM, Wol's lists wrote:
On 08/04/18 12:04, suse@a-domani.nl wrote:
On 2018-04-08 06:33, John Andersen wrote:
With your SSD almost as fast as ram, why are you so afraid of swapping?
Jack that swapiness up to 60 or more.
Wear of SDD perhaps ?
In reality, you'll probably find your drive is obsolete before it's worn out. cf that test that absolutely hammered a bunch of SSD drives and I think it took a year and more of almost continuous writes, rewrites and scrubs 24/7/365 before even the first drive failed. Most survived a LOT longer.
Cheers, Wol
This is the test you were probably referring to: https://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-... -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-09 21:13, Wol's lists wrote:
On 08/04/18 12:04, suse@a-domani.nl wrote:
On 2018-04-08 06:33, John Andersen wrote:
With your SSD almost as fast as ram, why are you so afraid of swapping?
Jack that swapiness up to 60 or more.
Wear of SDD perhaps ?
In reality, you'll probably find your drive is obsolete before it's worn out. cf that test that absolutely hammered a bunch of SSD drives and I think it took a year and more of almost continuous writes, rewrites and scrubs 24/7/365 before even the first drive failed. Most survived a LOT longer.
Cheers, Wol
OK, I'll dare doing it again. Some years ago, I applied one of my general autoyast files for installing suse on one of my fist sdd. (and with swap active, it gave block-errors after a year) But that was several years ago... Hans -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2018 10:55 PM, David C. Rankin wrote:
I went ahead and added a reduced swappiness setting in /etc/sysctl.d/99-sysctl.conf, e.g.
vm.swappiness=1
There doesn't see to be any reason for changing the default cache_pressure from 100, as the link indicated, e.g.
vm.vfs_cache_pressure=50
Reducing the rate the kernel will reclaim dentries and inodes due to memory pressure doesn't make a whole lot of sense. See:
I also put tmpfs on /tmp (many distros now do this by default, and I believe openSuSE is moving this way) systemd has a default tmp.mount file for this, it is in /usr/share/systemd/. All you need to do to put tmpfs on /tmp is symlink the file to /etc/systemd/system, e.g. # ln -s /usr/share/systemd/tmp.mount /etc/systemd/system Works fine: $ findmnt --target /tmp TARGET SOURCE FSTYPE OPTIONS /tmp tmpfs tmpfs rw,nosuid,nodev You can read the Fedora discussion here: https://fedoraproject.org/wiki/Features/tmp-on-tmpfs -- David C. Rankin, J.D.,P.E.
On 2018-04-08 17:08, David C. Rankin wrote:
I also put tmpfs on /tmp
(many distros now do this by default, and I believe openSuSE is moving this way)
No. Not that I know. There was a long discussion about it. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/08/2018 11:03 AM, Carlos E. R. wrote:
On 2018-04-08 17:08, David C. Rankin wrote:
I also put tmpfs on /tmp
(many distros now do this by default, and I believe openSuSE is moving this way)
No.
Not that I know. There was a long discussion about it.
Well, Regardless of whether openSuSE follows suit or not, it makes a lot of sense for SSD. Moving the volatile /tmp to RAM just eliminates that as a wear concern. The only concern is old apps that may write large amounts of data to /tmp (which they should have been re-written to write to /var/tmp). There shouldn't be any persistent data. I checked before the move and I had a total of 15k in /tmp from the past week of heavy use, so it's not a memory concern. I haven't had any issues though several reboots. I'll let you know if I see anything funny. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-08 19:30, David C. Rankin wrote:
On 04/08/2018 11:03 AM, Carlos E. R. wrote:
On 2018-04-08 17:08, David C. Rankin wrote:
I also put tmpfs on /tmp
(many distros now do this by default, and I believe openSuSE is moving this way)
No.
Not that I know. There was a long discussion about it.
Well,
Regardless of whether openSuSE follows suit or not, it makes a lot of sense for SSD. Moving the volatile /tmp to RAM just eliminates that as a wear concern.
But I don't have any such concern. Instead I have the concern that applications and people expect the contents of /tmp to survive a reboot.
The only concern is old apps that may write large amounts of data to /tmp (which they should have been re-written to write to /var/tmp). There shouldn't be any persistent data. I checked before the move and I had a total of 15k in /tmp from the past week of heavy use, so it's not a memory concern.
I haven't had any issues though several reboots. I'll let you know if I see anything funny.
There is no specification that says /tmp is short term. Not in the Linux filesystem hierarchy, AFAIK. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Отправлено с iPhone
8 апр. 2018 г., в 20:42, Carlos E. R. <robin.listas@telefonica.net> написал(а):
There is no specification that says /tmp is short term.
There is.
Not in the Linux filesystem hierarchy, AFAIK.
You may want to actually read Linux FHS. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-08 19:51, Andrei Borzenkov wrote:
Отправлено с iPhone
8 апр. 2018 г., в 20:42, Carlos E. R. <robin.listas@telefonica.net> написал(а):
There is no specification that says /tmp is short term.
There is.
Not in the Linux filesystem hierarchy, AFAIK.
You may want to actually read Linux FHS.
I did, but longggg ago. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/04/18 18:51, Andrei Borzenkov wrote:
Отправлено с iPhone
8 апр. 2018 г., в 20:42, Carlos E. R. <robin.listas@telefonica.net> написал(а):
There is no specification that says /tmp is short term.
There is.
Not in the Linux filesystem hierarchy, AFAIK.
You may want to actually read Linux FHS.
If you want stuff to survive in the short term, you need to use /var/tmp. The FHS is quite clear that if you stick stuff in /tmp, "don't expect to still find it there when you come looking". It's where you stick files that, when you close them, you're finished with them. /var/tmp is supposed to survive crashes and reboots, so it's where things like recovery files go. There's no time limit on validity, but it would not be wise to expect something still to be there that you last used a week ago. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sun, 08 Apr 2018, Carlos E. R. wrote:
There is no specification that says /tmp is short term. Not in the Linux filesystem hierarchy, AFAIK.
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html 3.18. /tmp : Temporary files [..] Programs must not assume that any files or directories in /tmp are preserved between invocations of the program. http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html 5.15. /var/tmp : Temporary files preserved between system reboots And I've had tmp on tmpfs for many years now... -dnh -- I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design. -- Andrew Tanenbaum to Linus Torvalds -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/08/2018 07:34 PM, David Haller wrote:
Hello,
On Sun, 08 Apr 2018, Carlos E. R. wrote:
There is no specification that says /tmp is short term. Not in the Linux filesystem hierarchy, AFAIK.
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html 3.18. /tmp : Temporary files [..] Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html 5.15. /var/tmp : Temporary files preserved between system reboots
And I've had tmp on tmpfs for many years now...
-dnh
I kinda always liked 'man 7 hier' for that one.. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Andrei Borzenkov -
Carlos E. R. -
David C. Rankin -
David Haller -
jdd＠dodin.org -
John Andersen -
Knurpht ＠ openSUSE -
suse＠a-domani.nl -
Wol's lists