I am going to clean install. My system has a 128Gb SSD and a 300Gb SATAII. Should the /swap partition be on the SSD or on the conventional drive? Also, same question for /home. I have 4Gb of RAM, and usually set Swap to 2Gb.
What is your usage of Swap. When you almost never use it, it is rather indifferent if it is fast or not.
Thanks, Henk. I thought that was probably the case, ISTR that were issues with swap on SSD’s with them wearing out with lots of write operations…?
I am not an SSD expert at all, but I would guess that depends on usage. And it is a trade off of course. And only you can take measurements on the system about Swap usage. Wouldn’t be to much with 4GB of memory, but I can only say that for the use I make of my system.
On 2014-10-15, wakou <wakou@no-mx.forums.opensuse.org> wrote:
> I am going to clean install. My system has a 128Gb SSD and a 300Gb
> SATAII. Should the /swap partition be on the SSD or on the conventional
> drive? Also, same question for /home. I have 4Gb of RAM, and usually
> set Swap to 2Gb.
Depends. Lots of things influence what is optimal e.g.
- Are you dual/multi-booting?
- Do you use your computer for anything memory-intensive?
- How much space do all your programs take up when you’ve installed everything you need.
- Is security an issue to the extent where you encrypt your data partitions?
Some general points about swap:
- A swap partition is not mandatory but recommended.
- A swap partition on an SSD will in general give you better performance than on an HDD.
- A useful swap partition size is exactly double your RAM.
Based on what you’ve said so far and assuming you don’t dual-boot, a reasonable partition arrangement could be:
SSD(sda): 1 GB /boot/, 119 GB /, 8 GB /swap/
HDD(sdb): /home/
Personally I like to have `complete’ Linux intalls on a single SSD, and like to accommodate for potential memory
upgrades, and so I’d probably do something more like…
SSD(sda): 1 GB /boot/, 95 GB /, 16GB /swap/, 16 GB /home/
HDD(sdb): multiple data partitions symlinked from /home/you/
Only 16 GB /home/ you might ask? Well, if you store your all your data on partitions on the HDD, you can easily symlink
to those partitions from /home/. The advantages of this approach are:
- You can rip out the SSD and stick it in another machine and still have a completely working system albeit with broken
symlinks in /home/you. - You can rip out the HDD and stick it into a new machine and have instant access to all your data without having to
copy them across. - If you need to reinstall/upgrade GNU/Linux on the SSD, you can do so confident in the knowledge that all your data is
intact on the HDD. - If you ever need to reformat /home/, it’s no big deal because all you need to do is recreate your symlinks
afterwards.
I suspect though there will be some here who disapprove of this approach…
sda is the 120G SSD in my system
sdb is the 1 T openSuse mechanical drive in my system
Partition Filesystem Mount Point Label
sda1 fat32 /boot/efi
sda2 ext4 / suse131-root
sda3 ext4 / mageia-root
sdb1 linux-swap swap
sdb2 ext4 /tmp suse131-tmp
sdb3 ext4 /var suse131-var
sdb4 ext4 /home suse131-home
sdc is partitioned for Fedora 20 and will have the mageia installation (soon)
sdb is a 10k WD drive so access is pretty quick.
I may have overdone the partitioning what with tmp and var on sdb. And, as I have 32G ram, it doesn’t matter where the swap file resides. But… I’m pleased with the response of my system.
/tmp and /var generally have a lot of write/erase activity. So could go to a HD. Note that modern SSD have pretty long projected life even if you write/erase multi gigs per day. I guess it is a matter if you intend to keep the drive active for either 5 or 20 years LOL
On 2014-10-15 09:46, wakou wrote:
>
> I am going to clean install. My system has a 128Gb SSD and a 300Gb
> SATAII. Should the /swap partition be on the SSD or on the conventional
> drive? Also, same question for /home. I have 4Gb of RAM, and usually
> set Swap to 2Gb.
You should have a bigger swap. Minimal would be 5. I would set it to 10.
Guessing that you have a laptop, you need a bit than the size of ram to
be able to hibernate, with a margin. And there are some ram hungry
applications, so 2 gigs of ram is too little.
There will be two issues with none or insufficient swap: if you need
assigning more memory than available, the kernel will kill things to
make space, and often crashes the system. And, before that, it will
sacrifice buffers and cache, making disk operations slower.
The popular saying that having swap space makes the system slower is
somewhat incorrect. What is true is that replacing the used swap with
ram, makes the system faster. If you can not add ram, then using swap
makes the system actually faster with that workload.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On Wed 15 Oct 2014 07:46:01 AM CDT, wakou wrote:
I am going to clean install. My system has a 128Gb SSD and a 300Gb
SATAII. Should the /swap partition be on the SSD or on the conventional
drive? Also, same question for /home. I have 4Gb of RAM, and usually
set Swap to 2Gb.
Hi
This desktop just has an OCZ Vertex 4 SSD in it at present;
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 119.2G 0 disk
├─sda1 8:1 0 512M 0 part /boot
├─sda2 8:2 0 40G 0 part /
├─sda3 8:3 0 70.8G 0 part /data
└─sda4 8:4 0 8G 0 part [SWAP]
Total GB Written: 1930.40GB or 0.243GBph
Lifetime hours: 7936
This is one of the notebooks with a Crucial M500;
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111.8G 0 disk
├─sda1 8:1 0 260M 0 part /boot/efi
├─sda2 8:2 0 40G 0 part /
├─sda3 8:3 0 63.5G 0 part /data
└─sda4 8:4 0 8G 0 part [SWAP]
Total GB Written: 185.01GB or 0.106GBph
Lifetime hours: 1732
Bot systems have elevator set to noop, and swappiness wound down;
vm.swappiness=1
vm.vfs_cache_pressure=50
If your running a ssd and rotating disk, then you probably need to look
at tweaking the i/o scheduler as well.
I would just run a ‘data’ type partition on the rotating drive and
symlink as previously suggested.
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-21-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
I put /home, /Swap and /var on my SATAII conventional drive to avoid excessive writes.
theory:
http://storagesearch.com/ssdmyths-endurance.html
practice:
http://en.opensuse.org/sdb:Ssd_performance
Make sure you check No Access Time in Yast2 for your ssd partitions.
Since your RAM is limited, this might eventually be an argument for a larger /Swap file on the conventional drive. However, this might only obtain if your RAM is extremely limited.
On 2014-10-17 17:46, hoogle wrote:
> practice:
> http://en.opensuse.org/sdb:Ssd_performance
That page does not exist, gives error here. It is:
http://en.opensuse.org/SDB:SSD_performance
The case is important.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Thanks for all the advice, folks. Although some of ot conflicts a bit… The SDB article says not to put swap on the SSD, or at least to set swappiness to a minimum value…
I found this nicely presented walk-through:
https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse
Which seems to cover the topic quite well. Is there anything with which people would disagree?
I have now (I think) set my /tmp to a tmpfs in RAM in two different ways. Will they conflict? How do I check that all is working correctly?
Here is mount:
linux:~ # mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1923408k,nr_inodes=480852,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
/dev/sda2 on / type ext4 (rw,noatime,data=ordered)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=24,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /tmp type tmpfs (rw)
/dev/sda3 on /home type ext4 (rw,noatime,data=ordered)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
This is the system in my sig, except that I am now using 13.2 RC1 and KDE 4.14.1. I have not got around to installing my multimedia files yet. I will put them on a HDD and symlink from /home?
Hi
You might want to look at adding the discard option to sda2/3 in your fstab?
Thank you Malcolm. If I have understood correctly, the advice here:
https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse
Not advised: by discard
8.3. Another widely used method for automatic TRIM is to add the option discard to /etc/fstab, to the line(s) for your root partition and for possible other Linux partitions that are being mentioned there. ***
Note:*** do not add it to the line for the swap partition, as that’s already being trimmed automatically by the system by default, during the boot process!
The disadvantage of this method is, that it may cause the system to slow down. Because it forces the system to apply TRIM instantly on every file deletion. That’s why this method is not my favourite.
So I added a trim on boot, using the advice on the same page…
Preferred method: by boot.local
8.1. You can add the TRIM command to /etc/rc.d/boot.local. Then this command will be executed automatically on system boot. This hardly slows the boot process down. This is the method that I prefer.
You can do that as follows:
a. If not done before: first install text editor Leafpad.
b. Open a terminal window (in Xfce: Menu button - System - Xfce Terminal).
Type:
su -
Press Enter
Type (use copy/paste):
leafpad /etc/rc.d/boot.local
Press Enter.
c. At the last line of the text in that file, you now add the TRIM command
fstrim -v for every automatically mounted EXT4 partition. ***
Note:*** not for partitions that aren’t mounted by default! And also not for the swap partition, as that’s already being trimmed automatically by the system by default, during the boot process.
An example is most clarifying. When your Ubuntu is on one single partition, so you have only the root partition / , then your rc.local should look like this:
#! /bin/sh
Copyright (c) 2002 SuSE Linux AG Nuernberg, Germany. All rights reserved.
Author: Werner Fink, 1996
Burchard Steinbild, 1996
/etc/init.d/boot.local
script with local commands to be executed from init on system startup
Here you should add things, that should happen directly after booting
before we’re going to the first run level.
fstrim -v /
If you have a separate home partition (although that’s not very useful), then you add the following line as well:
fstrim -v /home
Note: if you have a separate partition for /boot/efi, don’t add a line for that. It’s useless, as that partition is seldom being written to. And it may even cause malfunctions.
d. Save the modified file and close it.
e. Reboot your computer.
As usual I cannot pretend to understand fully, but if I have, this does the same job, but on boot?
Hi
I leave my desktop at the defaults for the moment, but do set swappiness;
cat /etc/fstab
/dev/disk/by-id/ata-OCZ-VERTEX4_OCZ-7B81SXCWP5VKVR6X-part2 / btrfs defaults 0 0
/dev/disk/by-id/ata-OCZ-VERTEX4_OCZ-7B81SXCWP5VKVR6X-part1 /boot ext4 acl,user_xattr 1 2
/dev/disk/by-id/ata-OCZ-VERTEX4_OCZ-7B81SXCWP5VKVR6X-part3 /data ext4 acl,user_xattr 1 2
/dev/disk/by-id/ata-OCZ-VERTEX4_OCZ-7B81SXCWP5VKVR6X-part4 swap swap defaults 0 0
/dev/sda2 on / type btrfs (rw,relatime,ssd,space_cache)
/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered)
/dev/sda3 on /data type ext4 (rw,relatime,data=ordered)
systemd-analyze
Startup finished in 2.639s (kernel) + 3.259s (userspace) = 5.899s
I haven’t worried about trim…
I beleive that the ‘SSD’ in FSTAB takes care of that when using BTRFS…?
linux:~ # systemd-analyze
Startup finished in 1.543s (kernel) + 1.712s (initrd) + 2.733s (userspace) = 5.989s
Throwin’ my 2 cents in (or whatever your currency happens to be)
-
Reviewing the official openSUSE SSD SDB at http://en.opensuse.org/SDB:SSD_performance
All recommendations seem reasonable to me <except ! > the one aboutflash memory I/O blocks
I’d want to do some research to verify, but what it says is not consistent with my understanding how most SSD (even HDD) works…- Modern disk firmware never automatically does a 1:1 disk block mapping when the software is using one size and the physical blocks are another size. It’s my understanding that the firmware nearly always will fill the physical block with as many software blocks as possible until the physical block is filled or the file has no more data to be written. And, this is aside from the fact that flash memory only presents a disk block as a virtual object to maintain legacy disk I/O functionality. I don’t know that even if there was some theoretical alignment issue on flash traps that there would be a significant measurable performance hit (although there would undeniably be wasted SSD space)
- The recommendation is based on articles which were written before 2012 (actually around 2009). I’ve written extensively (and based on more recent publications) that around 2012 manufacturers got their act together and started making SSDs with consistently similar and high performance. Although there are still significant differences between disks from different manufacturers, most of the really poor designs were weeded out around then. Unless you have one of those early generation SSDs, you need to carefully ignore any recommendations which originated 2011 and before (including re-printed after 2011).
-
Beware setting /tmp and similar highly used temp directories to tmpfs. Although it can have a major improvement in system speed, it can have adverse effects, perhaps the most onerous is limiting the size of file transfers. When a file is copied or moved from one location to another, a temporary copy is created in /tmp (or other similar location). If that temporary directory is deployed in RAM as tmpfs, you will be limited by the amount of RAM in your machine, so if for instance you only have 4GB physical RAM in your machine you probably won’t be able to copy/move a file larger than maybe 3GB. Even if you have more RAM, moving large files that utilize large amounts of RAM can otherwise affect the performance of your machine.
-
Setting swappiness and/or moving swap off your SSD can affect performance, particularly on machines with less physical RAM. Personally, and based on recommendations I’ve heard from disk manufacturers, I wouldn’t be worried about degraded life. If/when your disk starts to fail, it shouldn’t be an issue transferring to a new disk and when it finally might happen, SSDs will likelyb be very inexpensive.
-
Personally, I disagree with the recommendation at your referenced Easy Linux tips project to configure TRIM operations to perform only on bootup. IMO this has several potential problems
- Depending on the amount of read/writes, how often you boot and the size of the partition, the TRIM operation might not be performed in a timely manner. The whole purpose of executing TRIM is to guarantee the availability of SSD traps for writes.
- If you perform TRIM operations manually as described, it again does not guarantee SSD write availability.
- If you perform TRIM on bootup, you’re just delaying the operation to bootup, and still has to be accomplished so you’re likely slowing down bootup (although likely not by more than tens of seconds)
The whole point of running TRIM as a background service is to perform the operation automatically in as unobtrusive manner as possible in small short operations when your disk isn’t likely being accessed anyway. A fundamental concept of efficient design is to perform tasks like this in scheduled, tiny operations rather than all at once “on demand.”
- swap file on SSD, yes or no?
IMO the swap file should be placed on the SSD. I had not heard that TRIM is performed automatically on a SWAP partition, I’m surprised by that, in fact is completely opposite what is recommended at Archlinux which I consider one of my most reliable sources for this kind of information
Quoted from Arch Linux
- If using an SSD with TRIM support, consider using defaults,discard in the swap line in fstab. If activating swap manually with swapon
, using the -d or --discard parameter achieves the same. See man 8 swapon for details.>
Lastly, I consider the ability to monitor disk I/O in real time essential to knowing if your optimizations have any (or how much effect). I mention this in the PPT slide deck I created years ago and is still relevant to current versions of openSUSE
https://sites.google.com/site/4techsecrets/slide-presentations-30min
All IMO,
TSU
To add to what tsu2 has posted: I watched this thread with interest. I also read that sheet about not putting discard in the fstab file as it would slow down the system. I checked my fstab file and noticed that I had neglected to put the discard statement in it. So, after nearly a year of system updates going to that disk, I issued the command from a terminal screen. To my dismay, it took nearly 15 seconds to complete! Then, I noticed that it had processed 54 G (Gigabytes) of stuff! !!! So I created and deleted a couple of small files and tried again. My finger had not left the enter key before the process was done. I added the discard statement to my fstab file and have not seen any decrease in performance.
Perhaps, if I were using the SSD for data, and were crating and deleting huge files, I would see some slowness, but not with system files.
Bart
Can you please elaborate on this?
Maybe you could explain what you mean with “location” and what tools you are talking about.
IMHO, when I do a mv on the same file system, nothing is “copied” at all, only the administration in the directories file of the file system is adapted. When I mv to another file system, this is equivalent to cp.
When I do a cp from a file, the new file is written directly where it belongs, no intermediate file is created (what for should it do that?).
On 2014-10-20, tsu2 <tsu2@no-mx.forums.opensuse.org> wrote:
> - swap file on SSD, yes or no?
> IMO the swap file should be placed on the SSD. I had not heard that TRIM
> is performed automatically on a SWAP partition, I’m surprised by that,
> in fact is completely opposite what is recommended at Archlinux which I
> consider one of my most reliable sources for this kind of information
> Quoted from ‘Arch Linux’ (https://wiki.archlinux.org/index.php/swap)
I agree with TSU 100%. My experience from the i5-laptop to the Xeon workstation is that regardless of RAM (although I
haven’t tried with more than 128GB RAM), a dedicated swap partition on a SSD (especially with the new M.2 interface)
can produce some tangible benefit performance depending on memory load. I agree there are concerns with respect to
reliability so I always have at least two physical hard drives in one box (except in laptops…), an SSD for GNU/Linux
and swap (and boot and home), and a high capacity HDD for data. If there is a possibility of an SSD failing, I generally
don’t mind because:
- The most important files (i.e. the data) remain intact.
- A new SSD is trivial in cost these days.
- Replacing an SSD and reinstalling is trivial if you’ve scripted installation.
… and despite having such dual disk (SSD+HDD) arrangements in over dozen boxes for over 5 years, I’ve never had an SSD
fail. I therefore believe the reliability issues of SSDs have probably been exaggerated. A cynic might argue that these
exaggerations may have come from SSD manufacturors or OS vendors pushing TRIM support for purely commerical purposes.
I believe that having an SSD without dedicating a swap partition on it is much more likely to damage performance than
the drive…