On 26 November 2017 at 23:17, Carlos E. R. wrote:

Yes, by all means, get a small SSD and use it for Swap, but not only swap, also for the main system, excluding /home.

That means I need a 64Gb SSD. My current / is 46GB by df, but this is because of snapshots in btrfs (which made the system fail in the middle of upgrade to 42.3 - luckily I could recover by giving / some more space at the cost of /home - the joys of LVM). By du, / is about 18GB. So if I format the new / using ext4 and thus have no snapshots. I need 32GB for / to be sure nothing will break, I guess. And so, with swap, a 64GB SSD? I could probably afford something like this... https://www.amazon.co.uk/DREVO-X1-Pro-2-5-Inch-Internal/dp/B074GXGV9P/ref=sr_1_1?ie=UTF8&qid=1511742376&sr=8-1&keywords=ssd+64+gb It claims to have 400Mb/s read 300Mb/s write, compared to about 115 Mb/s for the existing HDD, but the latency is obviously much lower on any SSD... -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 27 November 2017 at 11:59, Carlos E. R. wrote:

...

That means I need a 64Gb SSD. If you use btrfs, double it.

After I was caught out during an upgrade with root full because of snapshots, I don't think I will be using btrfs again, sorry suse. Besides, SSD is too expensive for snapshots. I could simply do a manual snapshot to the HDD before large changes and perhaps cron it once a month. (But I do wonder how to create the right tar command that would not attempt to tar /home and other mounted stuff and /proc etc. Advice appreciated). so thanks for telling me about what you do. I thjink I'll go for 64Gb. 32 for root, 20 for swap, and the rest for a user-accessible place where I'll move stuff that needs speed (builds, some caches). I don't want to move /home to a small 12G space, I'm used to throwing stuff in /home without thinking of space. I'd rather have a fast place where I'd eed to do something explicitly. Any advice where to mount it? /vol/fast ? -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 27/11/2017 à 14:21, Mikhail Ramendik a écrit :

Besides, SSD is too expensive for snapshots.

sd is not more expensive than rotating disk was when needed

(But I do wonder how to create the right tar command that would not attempt to tar /home and other mounted stuff and /proc etc. Advice appreciated).

-x with rsync works well

I don't want to move /home to a small 12G space,

not needed

stuff in /home without thinking of space. I'd rather have a fast place where I'd eed to do something explicitly.

like what? I use ssd for main disk for more than a year now (480Go, just under €100 at the moment €129 today and only rotating for archiving jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 27 November 2017 at 13:38, jdd@dodin.org wrote:

...

I use ssd for main disk for more than a year now (480Go, just under €100 at the moment €129 today and only rotating for archiving

250 Go today, €66:

https://www.amazon.fr/Crucial-CT240BX300SSD1-BX300-Interne-Pouces/dp/B0742BC...

€70 here (ordering from .co.uk to Ireland) but similar. So I basically have a choice between 64Gb for 30 (which lets me put on root, swap, and the stuff that needs fast work) and 250Gb for 70 (and basically move everything except archive and downloads to SSD). I did find an option in the middle too, 128Gb for 50 https://www.amazon.co.uk/DREVO-X1-128GB-Internal-2-5-inch/dp/B01NBK3UE2/ref=... . That would let me move most everything to SSD too, but definitely avoid btrfs. Then it would be root 32G swap 20G home everything else. As long as gigabyte-sized downloads don't end up in home I should be good, but "watch what you download" is not really a runner in 2017. Just symlink ~/Downloads onto HDD?.. Or is Crucial very much better than Drevo?.. -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-27 at 16:02 -0000, Mikhail Ramendik wrote:

On 27 November 2017 at 13:38, jdd@dodin.org wrote:

...

...

I use ssd for main disk for more than a year now (480Go, just under €100 at the moment €129 today and only rotating for archiving

250 Go today, €66:

https://www.amazon.fr/Crucial-CT240BX300SSD1-BX300-Interne-Pouces/dp/B0742BC...

€70 here (ordering from .co.uk to Ireland) but similar. So I basically have a choice between 64Gb for 30 (which lets me put on root, swap, and the stuff that needs fast work) and 250Gb for 70 (and basically move everything except archive and downloads to SSD).

I did find an option in the middle too, 128Gb for 50 https://www.amazon.co.uk/DREVO-X1-128GB-Internal-2-5-inch/dp/B01NBK3UE2/ref=... . That would let me move most everything to SSD too, but definitely avoid btrfs. Then it would be root 32G swap 20G home everything else. As long as gigabyte-sized downloads don't end up in home I should be good, but "watch what you download" is not really a runner in 2017. Just symlink ~/Downloads onto HDD?..

Or is Crucial very much better than Drevo?..

I have /home on rotating rust. Yes, one option would be to have /home on SSD, and move (symlink) Documents and Download and whatever to the HDD. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlocY7AACgkQtTMYHG2NR9Uf8ACdFxgdlSguz60sfEKncE0V4RIQ C/IAni7HnFy7cwP8IIPUcY0wxi++Rc4f =mUrL -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-27 at 20:14 -0000, Mikhail Ramendik wrote:

On 27 November 2017 at 19:12, Carlos E. R. wrote:

...

I have /home on rotating rust.

Yes, one option would be to have /home on SSD, and move (symlink) Documents and Download and whatever to the HDD.

What's the option you are using? I don't think you use all 250 Gb just for / and swap?

I posted it on another post. I do it again: This is my current SSD layout: NAME KNAME RA RM RO SIZE TYPE FSTYPE LABEL PARTLABEL MOUNTPOINT UUID PARTUUID WWN MODEL ALIGNMENT sde sde 512 0 0 250059350016 disk Samsung SSD 850 ├─sde1 sde1 512 0 0 25769803776 part swap ssd-swap ssd-swap [SWAP] 4feaa6f5-... aa8fe1c7-... ├─sde2 sde2 512 0 0 15728640 part primary d96314db-... ├─sde3 sde3 512 0 0 16105078784 part ext4 ssd-test primary 68b54333-... 5ef2f590-... ├─sde4 sde4 512 0 0 1076887552 part ext2 ssd-boot primary /boot a977c5c3-... c3bbe83a-... └─sde5 sde5 512 0 0 161059176448 part ext4 ssd-main primary / ac173013-... ae6986d3-... There is swap, root, and an extra test partition (bootable). Notice that the root partition is big: Telcontar:~ # df -h /dev/sde5 Filesystem Size Used Avail Use% Mounted on /dev/sde5 148G 36G 105G 26% / Telcontar:~ # Thus It will be years till I have to expand with extra partition like /usr or /opt. Ample space for /tmp, too. And SSD works best with ample free space.

I'm in a toss-up between 128 and 250 Gb now. The good part about this is, this SSD can serve until it breaks. Unlike extra RAM, it is not tied to this motherboard. And the cost of going full-on SSD is broadly similar to the cost of doubling the RAM to 16Gb.

Right :-) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloddgMACgkQtTMYHG2NR9VU6wCfXmbW1uhyZ+6da22vmFkey34d e5MAoIcQKwS4CLkBWLKsV87d3lulpDXH =ME8m -----END PGP SIGNATURE-----

On Mon, 27 Nov 2017 13:21:24 +0000 Mikhail Ramendik wrote:

On 27 November 2017 at 11:59, Carlos E. R. wrote:

...

...

That means I need a 64Gb SSD. If you use btrfs, double it.

After I was caught out during an upgrade with root full because of snapshots, I don't think I will be using btrfs again, sorry suse.

I think the problem of root filling up with snapshots is the fault of snapper (an openSUSE program), not btrfs, even though the snapshotting capability is provided by btrfs. Please don't blame btrfs for problems not of its making. When you create the / partition at installation time, YaST offers an option to use snapshots, which you can decline if you want to. ISTR it defaults to 'yes' so you have enter the partitioning dialog to do this. Having said that, I understand that the default settings for snapper have improved in Leap 42.3. Don't know about other SUSE systems (SLES, TW) Bob -- Bob Williams System: Linux 4.4.92-31-default Distro: openSUSE 42.3 (x86_64) Desktop: KDE Frameworks: 5.32.0, Qt: 5.6.2 and Plasma: 5.8.7

On 27/11/17 12:25 PM, Mikhail Ramendik wrote:

But if I don't use snapshots, what's the point of having btrfs as opposed to ext4?

Isn't ext4 supposed to have snapshot capability as well? <quote src="http://snapper.io/faq.html"> Does snapper support ext4? Yes, but only experimentally and you need a special kernel and e2fsprogs. For more information see the next4 project. Does snapper support LVM? Since version 0.0.12 snapper can handle LVM snapshots with thin-provisioning. See the blog Snapper and LVM thin-provisioned Snapshots. </quote> But that may not be the solution you are looing for: <quote> How can I exclude directories from snapshotting? When you are using btrfs you can create btrfs subvolumes for the directories you want to exclude from snapshotting. Unfortunately there is no dedicated command to convert a directory to a subvolume. For all filesystem types you can exclude directories from snapshotting by making the directories mount points. </quote> Actually editing the config file gives you a great deal of control. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 27/11/17 17:25, Mikhail Ramendik wrote:

On 27 November 2017 at 17:15, Bob Williams wrote:

...

I think the problem of root filling up with snapshots is the fault of snapper (an openSUSE program), not btrfs, even though the snapshotting capability is provided by btrfs. Please don't blame btrfs for problems not of its making.

But if I don't use snapshots, what's the point of having btrfs as opposed to ext4? And on an SSD I just don't want any snapshots. I'll do them in other ways and onto the HDD, not SSD.

I believe btrfs does integrity checking. So if the underlying disk gets corrupted, btrfs will give you a read error because the CRC or whatever it is is broken. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Alternative suggestion. (Sorry if already mentioned). Get an SSD for your root partition. Use the full disk as root and set a swap file instead of a swap partition. This is the default behavior in a lot of distros now if a root partition is not specified. The default swap file size is normally 2.1GB. This way you can change your swap size easily when more disk space is needed. I believe swap files can also be dynamically allocated but I have never tried it. on my PC I have a 128GB Samsung evo SSD for / and a 1TB WD black Hard Disk for /home My system has 16GB RAM and I have a 16.1GB Swap file in / Take note of the sudo commands. Obviously make sure you omit sudo if you are running the commands in a root terminal. Check your swap configuration: cat /proc/swaps Turn off all swap: sudo swapoff -a or just the one file: sudo swapoff /swapfile Make swap file bigger (or smaller, just change the count= to MB e.g. 1024 for 1GB) In this case roughly 16.1GB sudo dd if=/dev/zero of=/swapfile bs=1M count=16486 Make the swap file useable: sudo mkswap /swapfile Turn on swap file: sudo swapon /swapfile Check your swap configuration again to make sure it has worked: cat /proc/swaps -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 28/11/17 15:22, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Tuesday, 2017-11-28 at 15:11 -0000, Paul Groves wrote:

...

Alternative suggestion. (Sorry if already mentioned).

Get an SSD for your root partition. Use the full disk as root and set a swap file instead of a swap partition. This is the default behavior in a lot of distros now if a root partition is not specified. The default swap file size is normally 2.1GB.

I'm unsure you can hibernate with that.

- -- Cheers,        Carlos E. R.        (from openSUSE 42.2 x86_64 "Malachite" at Telcontar)

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iEYEARECAAYFAlodfzYACgkQtTMYHG2NR9XejwCgiDxXxL8wpB8Erp/060YABAF7 bDAAn38sb1hZGqrKuzrDki1tXUCOUh/q =/R/D -----END PGP SIGNATURE----- Seems to work fine for me. The only thing is that the swap has to be at least the size of the RAM. So if you have 4GB Ram you need > 4GB swap to hibernate. So I would imaging this is where the .1GB comes in.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 28 November 2017 at 15:11, Paul Groves wrote:

Get an SSD for your root partition. Use the full disk as root and set a swap file instead of a swap partition. This is the default behavior in a lot of distros now if a root partition is not specified. The default swap file size is normally 2.1GB.

Thanks, but no need to change swap quite that often. LVM will do me just fine for the occasional change.

on my PC I have a 128GB Samsung evo SSD for / and a 1TB WD black Hard Disk for /home

Sounds fine, except with all of / on an HDD, you don't get the SSD advantage for builds etc? Or you just don't have those? I finally ordered the 250Gb SSD (caught last hours of sale on Amazon for the Crucial, thanks jdd for pointing that one out). I expect to do 40Gb / , 20 Gb swap, the rest /home, and symlink Downloads onto the HDD. Speaking of this, could anyone tell me where Leap keeps its RPM cache? I'd like to symlink that out onto the HDD as well. (This should be a new thread but I'm lazy so perhaps someone knows on this one :) ) -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 29 November 2017 at 19:56, Paul Groves wrote:

The only bottleneck I cam across was Virtualbox VMs being in /home by default so I made a directory on the SSD and symlinked it to my home directory.

I wonder - where in the tree is a good place for this stuff? you obviously had to put this on the root partition, so where under root? For partitions that are not on my main drive but on another drive that is permanently installed, I tend to use /vol - is this a good idea? For example, /vol/oldhome for what was previously /home on an older drive . I'll need to do this again for the HDD when I get the system working on the SSD. Another question - if I use the SSD for both / and /home, perhaps I should mount /var as a separate partition and put that on the HDD? This would apparently cover the RPM cache, but is there something in /var that might impact speed? -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-29 at 15:57 -0000, Mikhail Ramendik wrote:

On 28 November 2017 at 15:11, Paul Groves wrote:

...

Get an SSD for your root partition. Use the full disk as root and set a swap file instead of a swap partition. This is the default behavior in a lot of distros now if a root partition is not specified. The default swap file size is normally 2.1GB.

Thanks, but no need to change swap quite that often. LVM will do me just fine for the occasional change.

...

on my PC I have a 128GB Samsung evo SSD for / and a 1TB WD black Hard Disk for /home

Sounds fine, except with all of / on an HDD, you don't get the SSD advantage for builds etc? Or you just don't have those?

I finally ordered the 250Gb SSD (caught last hours of sale on Amazon for the Crucial, thanks jdd for pointing that one out). I expect to do 40Gb / , 20 Gb swap, the rest /home, and symlink Downloads onto the HDD.

You could do the same for Documents and Music, Video, etc.

Speaking of this, could anyone tell me where Leap keeps its RPM cache? I'd like to symlink that out onto the HDD as well. (This should be a new thread but I'm lazy so perhaps someone knows on this one :) )

Do not bother. In fact, doing so will slow down your updates and queries. It is /var/lib/rpm/, but it is about to change to somewhere under /usr that I forgot. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlofSqIACgkQtTMYHG2NR9U0PQCdF4YS/YSfsDLgI2aFDdrn59jT n5QAn25gb8ldZ1hMGUR7fpOmYW6B63Bw =92E3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 27/11/17 13:21, Mikhail Ramendik wrote:

On 27 November 2017 at 11:59, Carlos E. R. wrote:

...

...

...

...

That means I need a 64Gb SSD. If you use btrfs, double it. After I was caught out during an upgrade with root full because of snapshots, I don't think I will be using btrfs again, sorry suse.

Besides, SSD is too expensive for snapshots. I could simply do a manual snapshot to the HDD before large changes and perhaps cron it once a month.

(But I do wonder how to create the right tar command that would not attempt to tar /home and other mounted stuff and /proc etc. Advice appreciated).

--one-file-system ??? Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 27/11/2017 à 19:48, John Andersen a écrit :

On 11/27/2017 03:59 AM, Carlos E. R. wrote:

...

If you use btrfs, double it.

Never use BTRFS on an SSD. Even the BTRFS devs don't recommend it. They use to flat out say don't do it.

Now after 4.14+ they just say its not optimized, and won't trim properly. https://btrfs.wiki.kernel.org/index.php/FAQ#Is_Btrfs_optimized_for_SSD.3F

see also in depth explanation:

https://github.com/torvalds/linux/commit/583b723151794e2ff1691f1510b4e437102...

does this mean we have to remove the "ssd" option on btrfs system and is it possible without harm? thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 27 Nov 2017 19:35:29 -0500 Patrick Shanahan wrote:

* John Andersen [11-27-17 13:51]:

...

On 11/27/2017 03:59 AM, Carlos E. R. wrote:

...

If you use btrfs, double it.

Never use BTRFS on an SSD. Even the BTRFS devs don't recommend it. They use to flat out say don't do it.

Now after 4.14+ they just say its not optimized, and won't trim properly. https://btrfs.wiki.kernel.org/index.php/FAQ#Is_Btrfs_optimized_for_SSD.3F

see also in depth explanation:

https://github.com/torvalds/linux/commit/583b723151794e2ff1691f1510b4e437102...

guess my box is an anomaly. I have tw with btrfs root on ssd and have for at least 5+ years.

Theory and practice are often at odds! Thank $deity for the brave experimentalists. I'm also using btrfs on both ssd and spinning rust, though not as long as you. -- Bob Williams System: Linux 4.4.92-31-default Distro: openSUSE 42.3 (x86_64) Desktop: KDE Frameworks: 5.32.0, Qt: 5.6.2 and Plasma: 5.8.7

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2017-11-26 at 18:23 -0500, Greg Freemyer wrote:

On Sun, Nov 26, 2017 at 5:18 PM, Mikhail Ramendik <> wrote:

...

Be extremely careful about performance on low cost SSDs. I buy SanDisk thumb drives routinely and they don't come close to matching M.2 NVMe SSD speeds.

Ah, good point. For this usage one needs a fast SSD, one that supports sustained writes at good speed. Much faster at writes than a rust disk. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlobT1UACgkQtTMYHG2NR9X3OACglTYLXsTfFGJEYtbVxqBPckzN RowAoI9z7y7VSt2mX2PQs64MzIGERYIN =PCxw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, Nov 26, 2017 at 7:21 PM, Mikhail Ramendik wrote:

On 26 November 2017 at 23:23, Greg Freemyer wrote:

...

If you can get a high-performance 32GB SSD for 25 Euro, please let us know. I will be surprised if you can.

Looking at Newegg, the cheapest M.2 NVMe SSE they have is about $50. I would worry a lot about the performance of anything cheaper than that.

I'd have to get an NVMe controller too. Won't happen.

NVMe is the fastest, but you can get fast SATA too. But whatever you buy, test it an make sure it gets at least 100 MB/sec transfer rate. For NVMe I get over 1.5 GB/sec. And if you have a PCIe slot, all you need is a passive card. This one from Newegg is $12. https://www.newegg.com/Product/Product.aspx?Item=9SIABP565E1156&ignorebbr=1&nm_mc=KNC-GoogleMKP-PC&cm_mmc=KNC-GoogleMKP-PC-_-pla-_-Data+Adapters-_-9SIABP565E1156&gclid=Cj0KCQiAjO_QBRC4ARIsAD2FsXPWrxrUfr5GMR6sw8xFjx23NHlGUp4FeAqUdfCHTkzjgyorudEoV1QaAgyKEALw_wcB&gclsrc=aw.ds -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Monday, 27 November 2017 22:20:12 ACDT Carlos E. R. wrote:

On Sunday, 2017-11-26 at 20:48 -0500, Anton Aylward wrote:

...

On 26/11/17 05:18 PM, Mikhail Ramendik wrote:

...

As this is for swap only, I can get a cheap SSD (if it breaks I just lose one session). I can get a 32Gb SSD for about 25 Euro, while an extra 8GB of RAM would apparently set me back more like 50 Euro. But will this work?

In those circumstances I'd go for more memory first. late model Linux doesn't have a hard boundary between buffer space and program space any more, so it figures out where best to use the memory according to circumstances.

I went the exact same route as he, and I have noticed a huge speed improvement after placing swap on an SSD. It works, proven fact :-)

I have this instant 3.8G used swap.

Telcontar:~ # free -h total used free shared buffers cached Mem: 7.8G 3.5G 4.3G 53M 107M 899M -/+ buffers/cache: 2.5G 5.3G Swap: 23G 3.8G 20G

...

Swap is used ONLY when there isn't enough memory.

And there isn't.

...

I'll grant you that maybe you'll still end up with not enough memory, but when that happens to me I've always traced it to

a) a memory leak

No leaks. Just huge programs.

...

b) too many open ... whatever.

And I want all that open :-)

-- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar)

I have 16GB RAM and no swap. I haven't had swap enabled for 4+ years. Only once have I come close to needing it, when I had 2x Win7 instances running in VirtualBox (1x 32bit, 1x64bit) and tried to start a WinXP VM as well, forgetting that I already had 12GB allocated to VM's and Linux was using close to 4GB. Normally, even with Firefox and Chrome running (yes, sometimes both, but usually only 20 or so tabs each), I don't even come close to needing to swap. IMHO, if you can do it the best cure for slow swap speed is enough RAM that the system doesn't need to swap. Ever. :) -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2017-11-28 at 16:37 -0000, Wols Lists wrote:

On 27/11/17 04:08, John Andersen wrote:

...

I've never been more pleased with the performance of this old machine.

Soon as I get it to 4.14 I'll be happier yet, because swap is gaining a multiple pointer system into swap space, one for each core. See https://lwn.net/Articles/704478/ That means swap is not going to be a bottle neck any more.

The case for encouraging swap use is getting STRONGER, not weaker. https://lwn.net/Articles/690079/

If you've got multiple drives, provision swap on EVERY drive, then in fstab set "pri=x" to the same x for all of them. That will then create a *striped* array for swap, improving performance.

This is what I had on my computer, but the performance in Leap was bad. It was good enough in 13.1. That's why I had to buy an SSD.

That said, on my new system I'm going to set swap up as raid-10 with mdadm, which gives the benefits of both at the expense of a bit of disk space.

You really do not need that unless you run your machine 24*7.

...

Don't be stingy when provisioning swap space on an SSD. SSD's need to be over provisioned to protect device life cycle. Got 8 gig of ram? 16 gig of swap is not too much.

As far as I'm concerned the old rule of "no swap or at least twice ram" still applies. Everybody said the "twice swap" rule was an old wive's tale, even before linux was born, then kernel 2.4.0 hit and people found out the hard way it wasn't. I don't know whether the fundamental algorithm has changed since then (that was the trigger for a major rewrite of the swap subsystem), but hey disk is cheap so I take the *maximum* ram my mobo supports, double it, and provision that *per disk*. So I currently have 64GB swap (16GB ram times two times two disks). That's going up to 256GB on my new system (64GB max ram times two times three disks times raid-10) when I get it up and running.

The rule of "twice the ram" was a Windows 3 rule. And it was a rule because a) we used as much swap as we could, because RAM was scarce and expensive, and b) the max swap the system allowed was twice the RAM. There is no such rule in Linux; simply use as much as you need. In Linux I have run machines with about 30 times SWAP/RAM ratio. It worked fine - albeit slowly, of course. Yes, that amount of swap was needed, there was a memory hole in YaST that ate ram when updating. In this desktop machine the ratio is 3.

(Admittedly, that system is gentoo, so I mount /var/tmp/portage as tmpfs and that needs about 20GB for things like LO, GCC etc.)

NB - If you've got a small SSD, set "pri=1" for the SSD, and "pri=2" (or is it the other way round? Look it up) for the HDs, and linux will preferentially use the SSD, only using rust when the SSD is full.

Yes, good idea. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloewGUACgkQtTMYHG2NR9XCmQCdEIICWvUGzQ+nbjUUT+ES7bTi p+YAn2mN2SEP5XxPPA72cx2RdQ0O/LJa =A4il -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Wol & Carlos, et al -- ...and then Wol's lists said... % % On 29/11/17 14:12, Carlos E. R. wrote: % >The rule of "twice the ram" was a Windows 3 rule. And it was a ... % >There is no such rule in Linux; simply use as much as you need. % % And this "twice ram" predates Windows, let alone Windows 3. And Linux, too. % % Try running a *vanilla* early 2.4 series kernel with swap == ram. As % soon as the system even *touches* swap IT WILL CRASH. [snip] In fact, try running a nice old SunOS 4.0 UNIX or, I think (but am not sure) even classic ATT v7. The 2x rule is *very* old. It was explained to me as the system first loading into memory a copy of the executable and then running it from there, ostensibly to avoid corrupting the copy on disk but perhaps also for speed reasons (although swap was just as slow, so I never bought into that), which means both the static and running copies == 2x the usage. In any case, nobody ever had enough disk to spare to go more than 2x, and the OS didn't like it at less than 2x, so 2x it always was :-) Happy Holidays :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 29/11/17 23:58, Carlos E. R. wrote:

When I used Windows 3 (call it swap or whatever, does not matter), of course I tried to use more than 2x ram. I had ample disk space, what I did not have was ram. Windows said, AFAIK, fine, but I will nevertheless not use more than 2x. I can't.

Sorry. It DOES matter. Or do you want to live in a humpty-dumpty world where people can't understand each other despite everyone using the same words? Swap is not page. Swapping is a completely different technique from paging. Okay, if you just mean "transferring stuff to disk to free up ram", then there is no superficial difference between the two. But now you know the difference, *please* don't use the wrong word. They may do the same job, but Linux and Windows use two completely different techniques, with different names, and using the wrong word will confuse people - including yourself - and could easily cause problems if it's important enough to make a difference. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 30/11/17 03:14, Carlos E. R. wrote:

On Thursday, 2017-11-30 at 00:21 -0000, Wol's lists wrote:

...

On 29/11/17 23:58, Carlos E. R. wrote:

...

When I used Windows 3 (call it swap or whatever, does not matter), of course I tried to use more than 2x ram. I had ample disk space, what I did not have was ram. Windows said, AFAIK, fine, but I will nevertheless not use more than 2x. I can't.

...

Sorry. It DOES matter. Or do you want to live in a humpty-dumpty world where people can't understand each other despite everyone using the same words?

...

Swap is not page. Swapping is a completely different technique from paging.

...

Okay, if you just mean "transferring stuff to disk to free up ram", then there is no superficial difference between the two. But now you know the difference, *please* don't use the wrong word.

...

They may do the same job, but Linux and Windows use two completely different techniques, with different names, and using the wrong word will confuse people - including yourself - and could easily cause problems if it's important enough to make a difference.

It doesn't matter AT ALL.

YES, it is the same thing, different names, that's all.

See Anton's definition of swapping - the COMPLETE process gets dumped to disk. As I understand paging, PART of a process gets pushed aside to make room. What DIFFERENCE it makes, I have no idea, but the underlying techniques are fundamentally different. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 30/11/2017 à 11:08, David T-G a écrit :

the write nomenclature. It's either running or not, and whether it's "swapped out" or "paged out" in the latter case is immaterial to the unwashed masses.

yes :-) I used to use "paging" for ram jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2017-11-30 at 16:13 -0500, James Knott wrote:

On 30/11/17 07:30 AM, jdd@dodin.org wrote:

...

Le 30/11/2017 à 11:08, David T-G a écrit :

...

the write nomenclature. It's either running or not, and whether it's "swapped out" or "paged out" in the latter case is immaterial to the unwashed masses.

yes :-)

I used to use "paging" for ram

Anyone here remember overlays?

I do. I used then with Borland Pascal. Borland C also had them, I think.

Many years ago, I used to work on Data General Nova computers. They had 8 or 16 KB of memory and head per track disks. The first 20 tracks, IIRC, of the disk was reserved for overlays, which were blocks of code that could be quickly loaded as needed. There was even a write protect switch for those overlay tracks.

Ah, then, that's different. There was an exe file and an .ovl file, IIRC the name. The program would, under its own control, load sections of itself as needed. I could control the memory size of that area (for code) and some other size, some ovl size akin to swapiness control. Too long ago to remember the details. It was fantastic when the RAM was limited to 640 KiB! Another posibility that I used (in C) was to dump almost the entire program that was running to a file on disk (or perhaps on extended/expanded memory if you had it), except for a small stub that had to be at the start of the program memory image, and then load a second program. We could transfer data from loader to child using another data file. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlogesMACgkQtTMYHG2NR9XUdgCdHKIdAkAVHuTprYNuiqnRWM59 ZOUAn3tpTx1KT9F02qIbTetTZthDugOC =tsWm -----END PGP SIGNATURE-----

On 30/11/17 05:07 PM, David T-G wrote:

James --

...and then James Knott said... % % On 30/11/17 07:30 AM, jdd@dodin.org wrote: % > % > I used to use "paging" for ram % % Anyone here remember overlays? Many years ago, I used to work on Data % General Nova computers. They had 8 or 16 KB of memory and head per [snip]

Yes, although I was never smart enough to be able to actually play with the code. It was just this magic thing the software did to allow one to access "large" amounts of memory with those tiny 8-bit chips :-)

The Nova was 16 bit, so 8 KB was 4 K words. IIRC, the disks were 128, 256 or 512K, depending on the model. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 30/11/17 05:00 AM, Wols Lists wrote:

...

See Anton's definition of swapping - the COMPLETE process gets dumped to disk.

As I understand paging, PART of a process gets pushed aside to make room.

What DIFFERENCE it makes, I have no idea, but the underlying techniques are fundamentally different.

It makes a fantastic difference in the demands it paces on the hardware. Paging, which is actually short for 'demand paging' means you can pull many tricks with performance, but, as with everything, it is a compromise. This starts with the memory being accessed being 'not there'. Well, actually the mapping says that the referenced page hasn't been loaded. So you get a fault. The OS has to go off an get the relevant page of the code (or data) from disk and while it is doing so that process is suspended and another one can run. BUT, and this is the big issue, there needs to be the hardware capability to restart the instruction that caused the fault. THAT is non trivial. It is also a capability the PDP-11 didn't have. So the PDP-11 UNIX worked as 'rill in/roll out of the whole process. Today's Linux doesn't need the whole process space loaded. The request accessed pages of a process tend to stay in memory. "Tend to" is the operative. There is a complex queuing system that has a number of control parameters. Infrequently accessed pages end up at the end of the queue and migrate off to the disk; this is 'paged out'. The ones in make up the 'resident set'. This mapping technique is what lets programs share libraries. it is all about - yes, you guessed it - pointers. :-) Yes, the way the code that makes up a program, where the pages are, how much 'jumping around between pages' it makes DOES matter. The Principle of Locality becomes VERY important. It is nice to have the start-up/initialization code be on a page that gets swapped out and ha nothing else reference anything on that page :-) making use of the libraries is a Good Thing. making use of things already loaded, like the shell, is a Good Thing as it references pages already paged in. That is about what is termed "The Working Set", what tends to stay in memory or is required to stay if you expect reasonable performance from the program. As it says at https://web.stanford.edu/~ouster/cgi-bin/cs140-winter12/lecture.php?topic=th... <quote> Working Sets: conceptual model proposed by Peter Denning to prevent thrashing. .... What happens if memory gets overcommitted? Suppose the pages being actively used by the current threads don't all fit in physical memory. Each page fault causes one of the active pages to be moved to disk, so another page fault will occur soon. The system will spend all its time reading and writing pages, and won't get much work done. This situation is called thrashing; it was a serious problem in early demand paging systems. </quote> I would delete "early". Back to 'swapping' for a moment: One advantage that the PDP-11 had was the dual bus plus the smart disk controller with its own DMA & MMU. The swap area for a process was a continuous area of disk so the swap was a simple start, range, GO! Stock V7 had a disk s arm scheduler that tried to be smart in its queueing. I found that if you simply tweaked it so that swap-out immediately went to the head of the queue the performance increased. Sadly, with virtual memory stems it is not so simple as it depends too much on the program mix, the design of the programs and more. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos -- ...and then Carlos E. R. said... % % On Wednesday, 2017-11-29 at 15:16 -0500, David T-G wrote: % % Please do not use a non-standard character, '%' to mark the quoted % part. Please use '>'. Other mail programs do not recognize it. We've had this discussion already :-) and I've been doing so for, what, twenty-five years by now. Any real mail program should easily be able to recognize my or any other character as a quote regexp. [That was actually your comment inserted into my text body without a quote char, so it's a bit misleading, as though I'm talking to myself. But, hey, I talk to myself all the time in the real world, so why not in an email, right? :-] HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per, et al -- ...and then Per Jessen said... % % > We've had this discussion already :-) and I've been doing so for, % > what, twenty-five years by now. Any real mail program should easily % > be able to recognize my or any other character as a quote regexp. % % Fyi, knode, pan and Thunderbird don't recognise it. Wait, what?!? I thought that TB had it years ago; that's one of the reasons I actually liked it a little bit as a GUI MUA. They took that away?!? I don't know knode or pan, I'm afraid, nor probably lots of others. And I don't go near gmail nor consider it a real user agent and so can't provide any opinion on it. HH :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 30 Nov 2017 11:02:46 +0100 Per Jessen wrote:

David T-G wrote:

...

Carlos --

...and then Carlos E. R. said... % % On Wednesday, 2017-11-29 at 15:16 -0500, David T-G wrote: % % Please do not use a non-standard character, '%' to mark the quoted % part. Please use '>'. Other mail programs do not recognize it.

We've had this discussion already :-) and I've been doing so for, what, twenty-five years by now. Any real mail program should what, easily be able to recognize my or any other character as a quote regexp.

Fyi, knode, pan and Thunderbird don't recognise it.

And FYI, Claws-mail can recognise it. In Preferences, there is an option "Treat these characters as quotes" -- Bob Williams System: Linux 4.4.92-31-default Distro: openSUSE 42.3 (x86_64) Desktop: KDE Frameworks: 5.32.0, Qt: 5.6.2 and Plasma: 5.8.7

On Thu, 30 Nov 2017 16:42:43 +0100 Per Jessen wrote:

Bob Williams wrote:

...

On Thu, 30 Nov 2017 11:02:46 +0100 Per Jessen wrote:

...

David T-G wrote:

...

Carlos --

...and then Carlos E. R. said... % % On Wednesday, 2017-11-29 at 15:16 -0500, David T-G wrote: % % Please do not use a non-standard character, '%' to mark the quoted % part. Please use '>'. Other mail programs do not recognize it.

We've had this discussion already :-) and I've been doing so for, what, twenty-five years by now. Any real mail program should what, easily be able to recognize my or any other character as a quote regexp.

Fyi, knode, pan and Thunderbird don't recognise it.

And FYI, Claws-mail can recognise it. In Preferences, there is an option "Treat these characters as quotes"

I wonder if TB might have that too - I have definitely seen such an option somewhere, just not sure if it was in TB.

I was more thinking of it being built-in - having to configure it explicitly is, well, a bit backward.

Not really. It allows you to add non-standard quote markers as you come across them. As well as '>', I have seen $, : ~ and even % ;-) -- Bob Williams System: Linux 4.4.92-31-default Distro: openSUSE 42.3 (x86_64) Desktop: KDE Frameworks: 5.32.0, Qt: 5.6.2 and Plasma: 5.8.7

Per, et al -- ...and then Per Jessen said... % % Bob Williams wrote: % % > On Thu, 30 Nov 2017 16:42:43 +0100 % > Per Jessen wrote: % > ... % >> I was more thinking of it being built-in - having to configure it % >> explicitly is, well, a bit backward. % >> % > Not really. It allows you to add non-standard quote markers as you % > come across them. As well as '>', I have seen $, : ~ and even % ;-) Don't forget ! as well. I supposed it would be rude to use # and comment out everything other people say :-) % % I got the impression from David that he thought '%' was standardized. Oh, no; I'm quite aware that I'm weird :-) But a good MUA will come preconfigured to recognize quite a handful as well as easily be able to accept more, and so I'd more than half expect that my text would be recognized right out of the box. HH :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos, et al -- ...and then Carlos E. R. said... % % On Wednesday, 2017-11-29 at 15:16 -0500, David T-G wrote: % % >...and then Wol's lists said... % >% % >% On 29/11/17 14:12, Carlos E. R. wrote: % >% >The rule of "twice the ram" was a Windows 3 rule. And it was a ... % >% Try running a *vanilla* early 2.4 series kernel with swap == ram. As % >% soon as the system even *touches* swap IT WILL CRASH. % >[snip] % > % >In fact, try running a nice old SunOS 4.0 UNIX or, I think (but am not % >sure) even classic ATT v7. The 2x rule is *very* old. % > % >It was explained to me as the system first loading into memory a copy % >of the executable and then running it from there, ostensibly to avoid ... % % I never heard of that static and running copies theory. Certainly % not true for Windows 3. [snip] Yeah, that was from a UNIX context. I never did any digging into the question, not least since I was still new and starry-eyed and trying to wrap my head around this weird :-) UNIX stuff. It was years before I was at the point of setting up my own first system and laying out partitions, at which point I simply took 2x (a whole 1/2 G, if memory serves :-) like I had "always" been told. And so the legend continued... Happy Holidays :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton -- ...and then Anton Aylward said... % % On 29/11/17 03:16 PM, David T-G wrote: % > I think (but am not % > sure) even classic ATT v7. % % LOL! % Old v7 was just a swapping system, it ran n the very basic PDP-11 (and others of % that era) that did not have paging and instruction restart. I'll accept that :-) My only PDP-11 experience was sitting at one a few times; I never knew anything about the internals. % % Processes forked by being swapped out, then the in-core version then being given % a new id etc. It wasn't so much 'copy-on-write' as 'copy by writing out to swap'. Ahhhh... Interesting! % ... % A bit theoretical ... but there you have justification. And isn't that what this entire subthread has become? ;-) HH :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/12/17 20:06, L A Walsh wrote:

Wol's lists wrote:

...

Try running a *vanilla* early 2.4 series kernel with swap == ram. As soon as the system even *touches* swap IT WILL CRASH.

---

   We are in the 4.x series, what does an early bug have to do with this issue?

It WAS NOT a bug. It was a deliberate decision by Linus, and it was explicitly pointed out in the release notes. Which means it has EVERYTHING to do with issue, in that the Unix swap algorithm requires twice ram to function efficiently. And when Linus *deliberately* removed the optimisation, it suddenly needed twice RAM in order to function AT ALL. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Wol's lists wrote:

On 01/12/17 20:06, L A Walsh wrote:

...

Wol's lists wrote:

...

Try running a *vanilla* early 2.4 series kernel with swap == ram. As soon as the system even *touches* swap IT WILL CRASH.

--- We are in the 4.x series,

delete> what does an early bug have to do with insert> what does an early recommendation

have to do with this issue?

It WAS NOT a bug. It was a deliberate decision by Linus, and it was explicitly pointed out in the release notes.

Fine, change bug=>recommendation.

Which means it has EVERYTHING to do with issue, Sorry, it's still over 10 year old advice.

I ran linux with 0 swap for years (from 2.0->to at least the late 2.6 series -- never crashed from lack of swap). Somewhere around then I read what linus said he used at home -- a small swap to allow for early pages that were used at boot to be swapped out (even w/o swap pressure). Now... and since 2006, I use an 8MB swap. When I first switched to that, it would get as much as 100K usage. But that seems to have fallen off, as now, with system uptime @ >3 months, I have 0 swap usage. W/enough memory swap isn't necessary for most users. When I had swap -- if it was ever used, it was a mandate: GET MORE RAM. You'll waste far less time in your life not swapping. The extra cost for ram is more than compensated by the extra time you'll have in your life. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2017-12-01 at 14:39 -0800, L A Walsh wrote:

Wol's lists wrote:

...

On 01/12/17 20:06, L A Walsh wrote:

I ran linux with 0 swap for years (from 2.0->to at least the late 2.6 series -- never crashed from lack of swap). Somewhere around then I read what linus said he used at home -- a small swap to allow for early pages that were used at boot to be swapped out (even w/o swap pressure).

Now... and since 2006, I use an 8MB swap. When I first switched to that, it would get as much as 100K usage. But that seems to have fallen off, as now, with system uptime @ >3 months, I have 0 swap usage. W/enough memory swap isn't necessary for most users.

If you hibernate the machine, you notice on return from hibernation that some swap remains used and never goes out, even after days of use. My theory is that there are code regions that only used once during program init, and never used again. Thus on hibernation as everuthing is swapped out, and later only those parts actually needed are restored, one ends with some swap in use, and curiously, more free ram than if you don't have swap ;-)

When I had swap -- if it was ever used, it was a mandate: GET MORE RAM. You'll waste far less time in your life not swapping. The extra cost for ram is more than compensated by the extra time you'll have in your life.

Yes, provided that you can get and install more ram. In my case and that of the OP, we simply can't. Eventually, I'll get a new board, new cpu, new ram... but not this year. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloh5jYACgkQtTMYHG2NR9X/QgCfZVSLjXA0jU0LC1Zeq1IVvSOJ TLMAnjwfnm+LK/rlQnkcqPRSvbao3IrQ =WizI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Dec 1, 2017 at 3:06 PM, L A Walsh wrote:

Wol's lists wrote:

...

Try running a *vanilla* early 2.4 series kernel with swap == ram. As soon as the system even *touches* swap IT WILL CRASH.

--- We are in the 4.x series, what does an early bug have to do with this issue?

...

...

In Linux I have run machines with about 30 times SWAP/RAM ratio. It worked fine - albeit slowly, of course. Yes, that amount of swap was needed, there was a memory hole in YaST that ate ram when updating.

In this desktop machine the ratio is 3.

The rule is "use as much as you like", agreed. But in order to work *efficiently*, the traditional Unix swap algorithm *needs* twice ram. It's a fundamental quirk of how it works.

---- Linux's virtual memory algorithms are not those used in Unix. I don't think you can find a "traditional Unix" system from anyone anymore. If you need kernel core dumps, then you need as much space in swap as you have in memory (for the core image). If you aren't doing kernel development and you have enough memory for your needs, swap doesn't get touched. An SSD may be faster than a hard disk, but is many factors of 10 slower than RAM. I.e. memory read/write speeds are in GB/s, while small random read/writes to an SSD will be 4 to 16 times SLOWER than listed sequential testing (comparing 4K R/W to sequential R/W on http://ssd.userbenchmark.com/). This works out to <100MB/s for an SSD swap. Translation: SSD's for swap/page are about 500-1000 times slower than using RAM.

Linda, Welcome back: I don't know why those benchmarks are so slow for the top of the line SSDs. I hit 1.5 GB/sec on my lab PC. (sequential write tests (I think, might have been read.)). X99 Motherboard. Samsung PM961 SSD The PM961 is a NVMe SSD. It plugs directly into the MB. No SATA/USB involved. If your MB doesn't have a M.2 NVMe slot, you can buy a PCIe adapter for $25 or so. You can't boot off a NVMe SSD in an adapter in general. But you can when the NVMe SSD is plugged directly into the MB. Highly recommended. High-end laptops now have NVMe SSDs integrated in. I didn't test it with random i/o, so I don't know what that would be like. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2 December 2017 at 00:03, L A Walsh wrote:

And the original poster wanted that type of drive? That' wasn't my impression, but if I missed that, you'd be right.

The benchmarks are for SSD-drives that take the place of hard-drives -- not motherboard attached ramdisks. -l

You're right, I'm going for SATA3 SSD (it is in the mail from Amazon already, a Crucial 250Gb). I know more RAM is faster. More RAM is also as expensive as the SSD. But the SSD will also speed up all things involving disk I/O, so I hope the general improvement will be no less significant than from a RAM upgrade. Besides, upgrading RAM can be tricky. I have a 2013 motherboard, it has a couple of DDR3 DIMMs running at 1600 MHz with a 1.65V power voltage. The modern DDR3 DIMMS are all DDR3L, so specced at dual voltage 1.5/1.35V - I am not at all sure how they will coexist with 1.65V. And then I'll have to get rid of it all as it becomes obsolete eventually - the CPU is pretty basic, a Pentium G2120 - while a 250Gb SSD is unlikely to become fully obsolete for much longer. -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 02/12/2017 à 13:52, Anton Aylward a écrit :

slots for removable devices. The problem for the hard drive is that the racking is not like most chassis, it requires a caddy,

hard drive do not *need* a caddy, it's only convenient. Any small (to not prevent cooling) foam do the job :-) you should also have an esata connector (there are several boxes for the same brand, small, medium and large) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2 December 2017 at 20:50, Greg Freemyer wrote:

I just don't want people to think in general NVMe SSDs with a $25 adapter is never the best option for desktop PCs.

Mikhail has chosen to buy a 256GB SATA interfaced SSD for ~$100.

For ~$150 he could have bought a 256GB NVMe (PM961) interfaced SSD and an adapter. That pair would be 3x or more the speed of a SATA SSD.

For him, the $50 was too much. For others it may not be.

Checked things. All prices in GBP as I buy the stuff off Amazon.co.uk even though I am in Ireland. I got the 250Gb SATA3 SSD for 62 GBP. That was the Cyber Monday sale and it is 80 GBP now. There is a 80GBP NVMe SSD but it has speeds similar to the one I bought (in the 500Mb/s range). An NVMe SSD with circa 1.5 Gb/s costs 112 GBP, and the controller costs 23 GBP. So the difference (between non-sale prices) is 112+23-80=55GBP, slightly above your threshold but it might just be taxes. Not sure what may have been on sale for NVMe. Yes, too big for me, and yes, perhaps not too big for someone else. -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 3 December 2017 at 09:36, jdd@dodin.org wrote:

Le 02/12/2017 à 22:21, Mikhail Ramendik a écrit :

...

Yes, too big for me, and yes, perhaps not too big for someone else.

on a laptop you need to have the right connector/interface

https://www.amazon.fr/dp/B00V01C376/ref=psdc_430354031_t3_B01MQU72O9

this one (in french, but you may find the same on english) explain the situation.

I say this because if you search "nvme" on (french) amazon, you get mostly M SSD device that seems to have only ssd speed (6Gb/s)

so if one wants nvme pcie speed he have to buy an other laptop

notice ssd versus rotating is already much better

I'm a big SSD fan - Every system I've owned for years has booted into an SSD, and even my router/home server uses SSD storage for everything besides backup. After playing with them at work, I've realised NVMe are significantly more exciting and I've just ordered the parts for my new home computer which will be the first machine I've built that doesn't have a single disk or traditional SSD In my case I chose the Samsung 960 Pro NVME at 1TB which come at about €560 each, but sequential read speeds of 3500MB/sec (not a typo, BYTES, not Bits), and write speeds of 2100MB/sec There are more reasonably priced options. If you're only interested in using an NVMe SSD for booting then you don't need 1TB; The 512GB model is half the price. Samsung also do an 'Evo' range which is a little slower (3200MB/sec & 1900MB/sec) but cheaper still, and offer a 250GB sized model for €126. This is what I'd recommend for someone who wants a reasonably cheap way of dramatically improving their OS and root filesystem application performance. But you don't need to go full NVMe - if you're not an SSD user yet, you should be, and you can achieve this without needing to buy a new system with spare PCI-E slots or dedicated M2 SSD slots You can get a Sata SSD off the shelf for under €100 and there is quite simple no cheaper or easier way to significantly reduce system boot times and application launch times. I wouldn't use an SSD only for swap - they're to good at everything else they do, but I do put my swap partition (swap size = RAM size if I care about hibernation, otherwise no larger than 2GB) on whatever SSD I'm booting to. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/12/17 09:28, jdd@dodin.org wrote:

My younger daughter complained her Lenovo tablet x220 was extremely slow (sorry, windows 7 user :-((), and I have to ack this, when all the computer is pretty high end for it's sales date (i5, 4Gb ram).

If you can cope with the apparent privacy invasion (I deliberately have NOT got an MS account), I would upgrade to Win10. It's actually a *good* blend of 7 and 8 - most amazingly :-) Apparently MS are killing it at the end of the year, but if you upgrade 7 to 10 via the "assistive technologies" route it's still free. Or if you search Amazon you can buy genuine OEM keys for about £10. I've done both. I shouldn't be advertising MS on a linux list :-) but if people *are* running windows I would personally recommend the upgrade. (Oh - and one of the systems I upgraded was a high-end Vista system. The owner was well pleased with the improvement.) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 3 Dec 2017 09:58:46 +0100 Richard Brown wrote:

In my case I chose the Samsung 960 Pro NVME at 1TB which come at about €560 each, but sequential read speeds of 3500MB/sec (not a typo, BYTES, not Bits), and write speeds of 2100MB/sec

There are more reasonably priced options. If you're only interested in using an NVMe SSD for booting then you don't need 1TB; The 512GB model is half the price.

I bought a new workstation a couple weeks ago and one of the options was various Samsung 960 NVMe PRO's including the 2 TB at ~$1300 (~€1100 ?) the later to which I said, umm, no thank you for that :-/ My question to you, and to Greg F who also apparently has experience with these things, is: these come with hardware encryption. How does that work with linux, specifically openSUSE of course. Can you boot 42.3 off a hardware encrypted NVMe? If so, anything special need to be done to permit said booting? Thanks. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 3 Dec 2017 18:47:03 +0100 Richard Brown wrote:

...

My question to you, and to Greg F who also apparently has experience with these things, is: these come with hardware encryption. How does that work with linux, specifically openSUSE of course. Can you boot 42.3 off a hardware encrypted NVMe? If so, anything special need to be done to permit said booting?

I haven't used it much myself - all of the production nvme openqa.opensuse.org workers (which were/are Leap 42.2/3) didn't use the feature - We don't want to enter passwords when we're rebooting them.

However I did my homework and currently the commonly believed 'best' way of using the hardware encryption is by using the support (if your BIOS has it) for unlocking it in and with the BIOS

That way, when the BIOS is loading, it unlocks the device, and from that point on Linux we see and use the device just like a regular nvme (which is pretty much seen the same as a regular disk, just with a funny naming convention, eg /dev/nvme0n1p1)

There are embryonic efforts for userspace and kernel tooling to enable the control and use of the hardware encrypted nvme support without needing to rely on BIOS support. I believe we have the kernel support in our kernels, I do not believe we have the userspace tooling packaged anywhere.

But, given the tooling would require the disabling of SecureBoot, which actually does a good job of ensuring your boot process hasn't been tampered with, a solution using this software would arguably have a wider attack service than the BIOS unlock or the more generic dm-crypt/luks option with SecureBoot we already support in our openSUSE Packages.

Thanks for that info. I don't see anything in this BIOS relevant to booting from an NVMe, whether encrypted or not, but that's possibly because there's no NVMe currently installed thus no need to display options. I pulled out Thunderbolt board; options for Thunderbolt in the BIOS disappeared, possibly same factor in play with the NVMe. 'opensuse-secureboot' (yes, that's what it says in this BIOS, not 'openSUSE-secureboot' ;-) works fine on this machine with three LUKS partitions but I don't boot from LUKS. That's the reason for my original question. Bootable encryption would be interesting to have. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: On Sunday, 2017-12-03 at 18:47 +0100, Richard Brown wrote:

On 3 December 2017 at 17:10, listreader <> wrote:

...

On Sun, 3 Dec 2017 09:58:46 +0100 Richard Brown <> wrote: ... I bought a new workstation a couple weeks ago and one of the options was various Samsung 960 NVMe PRO's including the 2 TB at ~$1300 (~€1100 ?) the later to which I said, umm, no thank you for that :-/

My question to you, and to Greg F who also apparently has experience with these things, is: these come with hardware encryption. How does that work with linux, specifically openSUSE of course. Can you boot 42.3 off a hardware encrypted NVMe? If so, anything special need to be done to permit said booting?

I haven't used it much myself - all of the production nvme openqa.opensuse.org workers (which were/are Leap 42.2/3) didn't use the feature - We don't want to enter passwords when we're rebooting them.

However I did my homework and currently the commonly believed 'best' way of using the hardware encryption is by using the support (if your BIOS has it) for unlocking it in and with the BIOS

That way, when the BIOS is loading, it unlocks the device, and from that point on Linux we see and use the device just like a regular nvme (which is pretty much seen the same as a regular disk, just with a funny naming convention, eg /dev/nvme0n1p1)

The advantage here is that the disk i/o is really fast, doesn't load the OS. There is /some/ support in hdparm for it (search "ATA Security Feature Set" on the man page). There is a huge caveat, though: when the password is entered via the BIOS, apparently the password itself is modified in a way that is difficult to predict, and the disk will only be operable on that machine and no other. If the machine breaks down, your data is lost. I read about this in a detailed article, but I don't remember the details in order to locate it, and it is not in my notes, sorry. Hopefully somebody else does remember and posts a link. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlolkawACgkQtTMYHG2NR9WJgACgjbrbiZsJ6zsnhFNOt2Seq+0K TgYAn0NIxX5vIzapdEdmguDZGi7c9BGa =zOkE -----END PGP SIGNATURE-----

On Mon, 4 Dec 2017 07:55:35 -0500 Greg Freemyer wrote:

...

My question to you, and to Greg F who also apparently has experience with these things, is: these come with hardware encryption. How does that work with linux, specifically openSUSE of course. Can you boot 42.3 off a hardware encrypted NVMe? If so, anything special need to be done to permit said booting?

That's a bios question, not openSUSE.

Most 3+ year old bios can't boot off of NVMe at all.

Machine build date is 2017-10-30. BIOS date is 2017-10-17. I don't see anything in BIOS/UEFI that deals with booting off a NVMe, encrypted or not, but maybe that's because there's no NVMe installed at the moment.

I just looked at a new AsRock X299 MB. It had 3 NVMe slots. They are current generation storage.

But then you live in a totally different world from the rest of us :-/ Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

I just don't want people to think in general NVMe SSDs with a $25 adapter is never the best option for desktop PCs. ... For me, I hope I've bought my last SATA interfaced SSD. It's a old, slow legacy solution as far as I'm concerned.

A large factor might be based on how many slots one has for each (PCIx v SATA ports) and what the PCIx requirements are: i.e. is it fine in a PCIx-1? How many lanes is your PCIx attachment? Seems like that would strongly affect I/O rates you would get. Another factor might be other usage -- like if you are wanting to include it in a RAID -- I noted that most RAID controllers didn't work with on-bus (NVMe) disks.

...

The benchmarks are for SSD-drives that take the place of hard-drives -- not motherboard attached ramdisks.

NVMe SSDs are current generation hard drives. They aren't ramdisks in any sense of the word. I bought my first one 2 years ago.

---- That you can't boot from. FWIW, I took a 4-disk SSD-RAID0 out of a non-booting system and put it into another, same model machine, and was able to boot it flawlessly. For that reason, I wouldn't call them hardware-based drives. From your description, it's memory that is physically attached via a PCIx interface to the motherboard, no? Memory attached to the system motherboard, used to be how memory was designed into the system before CPU speeds were so much faster than MB speeds (mostly gen-1 PC's and computers before that). The website I cited, doesn't consider them in its bench marks as they aren't hard-disk compatible (can be thrown in another pc to boot from, as 1 example). That DOESN'T mean they might not be a good value for the money. But sometimes being able to take the drive out and put it in another system w/no loss of data or functionality is important. It's too bad Windows can't simply use that type of drive as a cache for a regular HD like linux is supposed to be able to.

The $25 adapters only negative that I know of is that you can't boot off of them typically.

But, motherboards that have the built-in adapter also have boot support. Laptops with NVMe SSD support can also boot off them.

I would hope so..

fyi: it's a bit on the extreme side, but a client had a 2 TB NVMe SSD

nice, wonder how much that cost... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

...

FWIW, I took a 4-disk SSD-RAID0 out of a non-booting system and put it into another, same model machine, and was able to boot it flawlessly.

I just realized you said same model PCs. That would work with NVMe too. The entire model of PCs should either have, or not have NVMe boot support. An NVMe SSD is portable among all PCs that have NVMe boot support in the bios. I know X99 and X299 variety motherboards have NVMe boot support, but I assume many others do as well at this point. The easiest way to tell is to see if they have M.2 PCIe slots or not. If they have the slots, they should have boot support. A quick google finds this $70 MB with an integrated M.2 slot: https://www.newegg.com/Product/Product.aspx?Item=N82E16813157689 As I said, it is no longer exotic tech. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2017-12-17 at 15:34 -0600, listreader wrote:

On Mon, 4 Dec 2017 09:19:25 -0500 Greg Freemyer <> wrote:

...

An NVMe SSD is portable among all PCs that have NVMe boot support in the bios.

This. Data on a hardware encrypted NVMe (m.2) is transportable?

If the BIOS "salts" the password, no. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlo27yAACgkQtTMYHG2NR9UhEQCfcTEx7Q3dquBQKVElY3CHfFg5 DUEAniPRsUlANSwhsne9CofQVlt1DYFR =gbNj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-12-17 a las 17:12 -0600, listreader escribió:

On Sun, 17 Dec 2017 23:26:33 +0100 (CET) "Carlos E. R." <> wrote:

...

...

...

An NVMe SSD is portable among all PCs that have NVMe boot support in the bios.

This. Data on a hardware encrypted NVMe (m.2) is transportable?

If the BIOS "salts" the password, no.

So, does that occur? Is the encryption completely in the NVMe (m.2) circuitry or does the machine have input?

The problem is that you need the BIOS prompting for the password on boot, and the bios modifies it and passes the disk a modified password. There was an article on this, but I lost the link. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlo3IkoACgkQja8UbcUWM1zoqwEAgCmeZF2Rt1PbiEeESEx4pE8r zD0HnGyBBPoJVRM2ojQA/iGXdWHYwJfHySwNvbBnabRQYvrBWnbMWvz+qhrEd5pK =kCcu -----END PGP SIGNATURE-----

Greg Freemyer wrote:

That's because the controller includes a standalone bios. NVMe doesn't use a separate bios. The main bios has to have NVMe support if you want to boot off of it.

That must have been a design decision at some point? Otherwise it sounds just like SCSI and fibre controllers with extension BIOS'es. -- Per Jessen, Zürich (2.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-12-04 at 15:52 -0500, Greg Freemyer wrote:

On Mon, Dec 4, 2017 at 9:49 AM, Per Jessen <> wrote:

...

Greg Freemyer wrote:

...

That's because the controller includes a standalone bios. NVMe doesn't use a separate bios. The main bios has to have NVMe support if you want to boot off of it.

That must have been a design decision at some point? Otherwise it sounds just like SCSI and fibre controllers with extension BIOS'es.

Agreed.

I suspect the goal is that the adapter cards be extremely low cost so they have all the logic in the main bios.

Also, in 5 years, NVMe drives will be extremely common in normal laptops / desktops, so the management/boot logic might as well go into the main bios.

If they are connected to the address/data buses, there is no logic. I want sector number x, here, you have it. You directly address the sector. If it is what I imagine, there is very little logic involved. What about external disks? An USB box to handle an NVMe disk? - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlolvQ8ACgkQtTMYHG2NR9WbtwCfdxV52Zt1ZzUUdmoQhLekhjiW akEAn3D0CcIfwLS94rT7bu4XSZpjN0MN =Uu5L -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Monday, 2017-12-04 at 15:52 -0500, Greg Freemyer wrote:

...

On Mon, Dec 4, 2017 at 9:49 AM, Per Jessen <> wrote:

...

Greg Freemyer wrote:

...

That's because the controller includes a standalone bios. NVMe doesn't use a separate bios. The main bios has to have NVMe support if you want to boot off of it.

That must have been a design decision at some point? Otherwise it sounds just like SCSI and fibre controllers with extension BIOS'es.

Agreed.

I suspect the goal is that the adapter cards be extremely low cost so they have all the logic in the main bios.

Also, in 5 years, NVMe drives will be extremely common in normal laptops / desktops, so the management/boot logic might as well go into the main bios.

If they are connected to the address/data buses, there is no logic. I want sector number x, here, you have it. You directly address the sector. If it is what I imagine, there is very little logic involved.

There is still a PCI bus in the middle. -- Per Jessen, Zürich (2.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Dec 4, 2017 at 1:12 PM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Monday, 2017-12-04 at 08:31 -0500, Greg Freemyer wrote:

...

On Sat, Dec 2, 2017 at 7:40 PM, L A Walsh wrote:

...

Greg Freemyer wrote:

...

That's because the controller includes a standalone bios. NVMe doesn't use a separate bios. The main bios has to have NVMe support if you want to boot off of it.

...

For that reason, I wouldn't call them hardware-based drives. From your description, it's memory that is physically attached via a PCIx interface to the motherboard, no?

It is the same storage chips your SATA SSDs use. The hold data even when disconnected from power.

The SATA interface chips are replaced with PCIe interface chips. In legacy SSDs, the SATA interface chips are the throughput bottleneck, not the storage chips.

...

Memory attached to the system motherboard, used to be how memory was designed into the system before CPU speeds were so much faster than MB speeds (mostly gen-1 PC's and computers before that).

The website I cited, doesn't consider them in its bench marks as they aren't hard-disk compatible (can be thrown in another pc to boot from, as 1 example).

That's like saying "SATA drives aren't hard drives. My 1999 era PC doesn't have SATA ports, so they aren't portable between all PCs."

I work with my client PCs routinely. 10 in the last 2 weeks. 2 of those 10 had exclusively NVMe SSD for storage.

It may be leading edge now, but it isn't bleeding edge any longer.

fyi: I think my first client owned PC with NVMe storage was in 2015. At the time, I had no idea they would show up as /dev/nvme0n1, etc.

As I understand it, and explained on another mail list in Spanish, these NVMe disks which connect to the PCIe bus have in effect direct access to the data and address buses in the bus, meaning that in effect you address them as memory. More or less. This is why accessing them is so fast.

Not all are that fast, though.

Isengard:~ # hdparm -tT /dev/sda

/dev/sda: Timing cached reads: 2818 MB in 2.00 seconds = 1409.00 MB/sec Timing buffered disk reads: 1352 MB in 3.00 seconds = 450.59 MB/sec Isengard:~ #

Model=KINGSTON SMS200S3120G

It is in fact and "ssd msata" disk, not an NVMe

I'm only getting about 2x you. I'm surprised it's not faster: # hdparm -t /dev/nvme0n1 /dev/nvme0n1: Timing buffered disk reads: 2700 MB in 3.01 seconds = 897.29 MB/sec Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

On Sat, Dec 2, 2017 at 7:40 PM, L A Walsh wrote:

...

The benchmarks are for SSD-drives that take the place of hard-drives -- not motherboard attached ramdisks.

NVMe SSDs are current generation hard drives. They aren't ramdisks in any sense of the word. I bought my first one 2 years ago.

I've been looking at options for a replacement PC (old one died, ~2 years out of warranty and soldered-on BIOS became corrupt (joy!)). Reading a user guide (https://docs.broadcom.com/docs-and-downloads/host-bus-adapters/pub-005851_20... or https://tinyurl.com/ycnxbkjz) for one of the disk adapter options: a Broadcom (LSI) MegaRAID + HBA card that explicitly supports Tri-mode operation. (Tri=SAS, SATA and PCIe). They describe the supported speeds: • SAS data transfer rates of 12Gb/s, 6Gb/s, and 3Gb/s per lane • SATA transfer rates at 6Gb/s and 3Gb/s per lane • PCIe (NVMe) data transfer rates of 8 GT/s, 5 GT/s, and 2.5 GT/s per lane Of note: the PCIe "disks" list speeds in terms of memory transfers, not the Gb/s of SAS or SATA disks. I submit that they *are* non-volatile ramdisks in _most_ senses of the word. I don't see why that is a bad thing, it allows them to have memorythough it would exclude them from sites that are only focused on SATA/SAS based SSD hard drives. The speed-unit of "GT/s" (Giga-transfers/second) is the same unit used for accessing non-local-node NUMA memory. For multi-socket MB's, each socket has it's own memory. Accessing non-local comes at a noticeable cost -- on the order of 1.5x - 3x. PC's from ~7 years ago operated in the 4.8-6.4GT/s (Giga-transfers/s) and are now up to 10.4GT/s in current processors. That gives a comparison point to PCIe's 2.5 - 8 GT/s. That's likely to give around 2GB/s (I get up to a bit over 1GB/s with HW RAID using 7200RPM disks using a 3Gb/s bus speed (older generation computer). The random perf differences of the PCIe cf. my RAID, would likely be a few-to-several times greater than the linear. So much faster (and maybe replacing conventional HD's for PC's, but w/RAIDs still used for capacity -- at least for a while. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

...

I also think of a ramdisk as being bootable media.

I also "don't" think ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, Dec 12, 2017 at 10:37 PM, Andrei Borzenkov wrote:

13.12.2017 02:54, Greg Freemyer пишет:

...

...

...

I also think of a ramdisk as being bootable media.

I also "don't" think ...

Well, there are NVDIMMs, so theoretically why not ...

Andrei, Do you find the term ramdisk appropriate to describe NVMe SSDs? It just seems wrong to me. For instance, the idea of disconnecting a ramdisk from one computer and moving it to another and having the data still be readable doesn't sound like a ramdisk feature, but it works nvme ssd cards. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-12-13 at 13:27 +0100, Per Jessen wrote:

Greg Freemyer wrote:

...

On Tue, Dec 12, 2017 at 10:37 PM, Andrei Borzenkov <> wrote:

...

13.12.2017 02:54, Greg Freemyer пишет:

...

...

...

I also think of a ramdisk as being bootable media.

I also "don't" think ...

Well, there are NVDIMMs, so theoretically why not ...

Andrei,

Do you find the term ramdisk appropriate to describe NVMe SSDs?

It just seems wrong to me.

For instance, the idea of disconnecting a ramdisk from one computer and moving it to another and having the data still be readable doesn't sound like a ramdisk feature, but it works nvme ssd cards.

"ramdisk" doesn't right to me - years ago, we called it a solid-state disk.

Ramdisk is what it has always been, i.e. an emulated disk backed by main memory.

That's right. We can not use the term RAM DISK to name those new "disks" because the term currently means an emulated disk in internal RAM memory. The correct term is "solid state disk". They also are not ram disks because they do not use RAM chips. Or do they? - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloxK0cACgkQtTMYHG2NR9XZewCfblyiUJyPOXe27UrwAQcZ4ort U3EAnRiDpqRW08BNqeU3V+HK6Dwiymrv =KJj6 -----END PGP SIGNATURE-----

On Wed, Dec 13, 2017 at 8:29 AM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday, 2017-12-13 at 13:27 +0100, Per Jessen wrote:

...

Greg Freemyer wrote:

...

On Tue, Dec 12, 2017 at 10:37 PM, Andrei Borzenkov <> wrote:

...

13.12.2017 02:54, Greg Freemyer пишет:

...

...

> > I also think of a ramdisk as being bootable

media.

I also "don't" think ...

Well, there are NVDIMMs, so theoretically why not ...

Andrei,

Do you find the term ramdisk appropriate to describe NVMe SSDs?

It just seems wrong to me.

For instance, the idea of disconnecting a ramdisk from one computer and moving it to another and having the data still be readable doesn't sound like a ramdisk feature, but it works nvme ssd cards.

"ramdisk" doesn't right to me - years ago, we called it a solid-state disk.

Ramdisk is what it has always been, i.e. an emulated disk backed by main memory.

That's right. We can not use the term RAM DISK to name those new "disks" because the term currently means an emulated disk in internal RAM memory. The correct term is "solid state disk".

They also are not ram disks because they do not use RAM chips. Or do they?

Long ago I knew more about the chips. We used to refer to DRAM for dynamic ram. The bits in the DRAM chips would disappear in a few seconds (or less) of the data wasn't refreshed by a strobe. It is clear that NVMe SSDs don't use DRAM chips, but could one call the chips they use RAM, I don't know. I'm sure they have the internal erase block (EB) feature/architecture of SATA interfaced SSDs. The EB architecture means the data once written is stable until electricity is used to erase a block of memory for re-use. There is a controller that lives on the SSD that manages the EB allocation and sector mapping from a logical sector to a physical EB and internal EB offset. To me this is nothing at all like what I think of when I see the term RAMDISK. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/13/2017 09:09 AM, Wols Lists wrote:

And what about core ram? The earliest ram was magnetic core, such that you could switch a computer off WHILE IT WAS RUNNING A PROGRAM, and when you switched it back on, the computer would carry on - "suspend-resume" 1950s-style ... :-)

Actually, Williams tube storage predates core memory by a few years. https://en.wikipedia.org/wiki/Williams_tube. Prior to that, relays could provide a small amount of storage and there were even attempts at what we call DRAM, by placing capacitors on a rotating drum. Another early "storage" device was made with neon lamps. They could be turned on or off with an appropriate pulse and retain the state until the next pulse changed it. Also, I have worked with core memory. While it's true it retained the data, restarting did not resume from where it was. It started the program as it would when first loaded. To resume, you'd have to retain the state of the various registers which, in most systems, were not stored in memory. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/13/2017 09:27 AM, Carlos E. R. wrote:

Program counter, stack counter, flags... All "CPU" registers.

Stack pointer, not counter. It pointed to the location where the registers were saved/read. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/13/2017 03:37 PM, Dave Howorth wrote:

On Wed, 13 Dec 2017 09:48:50 -0500 James Knott wrote:

...

On 12/13/2017 09:27 AM, Carlos E. R. wrote:

...

Program counter, stack counter, flags... All "CPU" registers. Stack pointer, not counter. It pointed to the location where the registers were saved/read. Most machines with core memory didn't have stack pointers. Hardware support for stacks was rather late.

They didn't have CPUs either. Processing would be split between the arithmetic unit, or mill, the registers and the control unit.

You're talking to someone with a lot of experience with older gear. I spent years maintaining systems built with Data General Nova & Eclipse computers, along with DEC PDP-8 & PDP-11s. (I also worked on DEC VAX 11/780 and a couple of Pr1me computers.) In those systems, while there were not chips called "CPU", there were circuit boards. For example, the Data General computers had a 2 - 15" square board CPU. The Nova line used discrete logic, but the Eclipse used bit slice processors, AMD 2902 IIRC. It also had ROM with the microcode that programmed the instruction set. Back in those days, I worked right to the microcode level. The Nova had 4 registers, in addition to the program counter, and by using indirect addressing, a memory location could be used as a stack pointer. Compared to the Nova, the Intel 8080 CPU was, in some ways, advanced in comparison. My IMSAI 8080 had one of those. I believe the Eclipse may have had a stack pointer. It's been 28 years since I last worked with those DG & DEC computers. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/13/2017 04:37 PM, Dave Howorth wrote:

You're a decade or so too late then. You're talking about minicomputers, which hadn't been invented, and ICs neither. When disks were 6' in diameter and 8' high drums were common. And yes I wrote disk driver code in microcode too. By the time of minicomputers, core was pretty much replaced by RAM - it meant the printers were no longer good places to warm yourself in the machine room.

Well, the oldest "computer" I worked on was built with vacuum tubes, relays and had a drum for storage. It was installed before I was born! ;-) Beyond that, the computers I worked on had ICs. The Data General Nova was created in 1968. However, at my office we had some older computers from Collins, which had transistor modules, instead of integrated circuits. Those systems also had 4' disks, with a 3 phase drive motor, 6" shaft and heads the size of a dollar coin. They were also water cooled. However, I didn't work on those ones. There was also a Phillips DS714 system that used transistors and drums. All the Nova computers had core memory, but the Eclipse had core or DRAM. I still have a core memory plane from one of those old Collins computers. Also, back then, we could keep our lunch cool under the raised floor! :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Has this list not become the official OFF-TOPIC list? or can we return to the described purpose for the list? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 13/12/17 23:57, listreader wrote:

On Wed, 13 Dec 2017 18:01:40 -0500 Patrick Shanahan wrote:

...

Has this list not become the official OFF-TOPIC list?

or can we return to the described purpose for the list?

Well, that's what I was hinting at, Patrick, only in a MUCH nicer way than you just did. ;-)

Sorry, but if you don't like it, can't you just kill this thread? Oh - I know not all mail readers seem to support that easily :-( IME, trying to stamp out off-topic (especially OT that confines itself to a few threads) has this nasty habit of stamping out *everything*. Please don't go there and turn this list dry as ditchwater. Anyways, this thread is all about computers, and of interest to quite a few people. Yes it's not particularly SUSE, but everybody taking part is (I think) a SUSE user? (Or try and get people to do, as happens on another list I use, at least flag all OT messages with "[OT]" for easy filtering.) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 13/12/2017 15:55, Greg Freemyer wrote:

Long ago I knew more about the chips. We used to refer to DRAM for dynamic ram. The bits in the DRAM chips would disappear in a few seconds (or less) of the data wasn't refreshed by a strobe.

It is clear that NVMe SSDs don't use DRAM chips, but could one call the chips they use RAM, I don't know. I'm sure they have the internal erase block (EB) feature/architecture of SATA interfaced SSDs.

The EB architecture means the data once written is stable until electricity is used to erase a block of memory for re-use. There is a controller that lives on the SSD that manages the EB allocation and sector mapping from a logical sector to a physical EB and internal EB offset. To me this is nothing at all like what I think of when I see the term RAMDISK.

Greg It's official, the nand flash chips used by ssds and nvme disks are block readable and writable only, so they can't be classed as random access memory which every location from address 0 and up is accessable in a random fashion. Dave P

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 14/12/2017 15:09, Carlos E. R. wrote:

Ah, this is what I thought. So the motherboard can address directly a block, not a word, on these devices. Once the block is addressed, I does something to transfer to RAM, either inside the disk or on the mother board. I suspect first to internal RAM, then this RAM is directly accessible from the motherboard, maybe via DMA. Unless there is a way to do a DMA transfer directly from the nand flash, emulating direct access to a position even if it is sequential. Some trick I can just imagine but not describe. Same as any disk where you have to read 512 bytes or one sector into memory to access one byte. Not sure but I think that some large disks have physical sectors of 4096 bytes. Dave P

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 15/12/17 00:31, Felix Miata wrote:

Dave Plater composed on 2017-12-14 17:53 (UTC+0200):

...

Not sure but I think that some large disks have physical sectors of 4096 bytes.

Most (if not all) >500GB made in the past ~6 years have 4Kb physical sectors: https://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-...

Drifting off topic (if not more here), while most drives had a compatibility mode, many newer drives do not. If your drive ONLY supports 4K sectors, and your fdisk or gpt or whatever has an "off-by-one" specifying the partition size in 512B sectors, then this can cripple disk access speeds. (I think I've explained it right - but it's definitely an "off by one" problem, and if your disk performance is awful, that could be why) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

I think we are in a semantics discussion. To me a non-volatile ramdisk is an oxymoron. I also think of a ramdisk as being bootable media.

--- Originally, (mid 50's up to about mid 70's) memory defaulted to being non-volatile (magnetic core memory). By the end of the 70's, most of that had been replaced by 'dynamic' RAM (DRAM) -- which needed constant refresh to hold its value. In other words, non-volatile RAM was the default. Random Access Memory can include volatile or non-volatile. Richard Brown wrote:

My new home system has 2TB of NVMe storage and no HDD or SSD storage each NVMe is benchmarking at speeds of 3100GB/sec (read) and 2300GB/sec (write)

No question that NVMe devices, being directly attached to the MB, are fast. I compared their transfer rates to the cpu-to-cpu memory transfer rates (meaning from 1 cpu socket to another).

I could set them up as a RAID if I wished (AMD Bios' support it at least)

So I don't think it's fair to categorise things the way you have.

I don't see them as being as portable as SAS or SATA drives which have an established, *architecture-independent* specification. The PCIe drives are limited by slots on the motherboard -- and I having to open up a workstation to unplug a disk and use it elsewhere is hardly convenient. As for a RAID, I'm not thinking a few disks, but allowing for a batch of 24 in a 12x2 RAID0-Mirror (aka RAID10). No way Greg's gonna see slots on an X99 board for 24 of those -- even 4T each would be insanely expensive, let alone a compliment of 10TB drives out of SSD (even if they were available).... PCIe drives really don't fall into the category of "peripherals" like most drives do -- they aren't portable between architectures like SCSI or SAS drives can be. How does 'fair' enter in to disk categorizing? I thought it was more about 'utility'. If the PCIe drives can sit in unpluggable containers outside the computer, then I might not think they are in a separate category, but as long as they have to be attached to the MB, I have a hard time seeing them as other than a type of ramdisk that can be addressed like a disk, but is still RAM (of a sort) sitting on the motherboard like main memory. Main memory for other cpu-chips on the MB are only addressable through the their local CPU and have their speeds measured in the Gt/s (Giga-transfers/second) in the same range as the PCIe 'disks'. They likely have their own controller (another cpu) to talk through and handle emulation. In that regard they share more with NUMA than either peripheral HD's OR on-board, local memory. I would also agree w/Greg, that whatever one wants to call them, its mostly a matter of semantics/definitions.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

Here's an 8 slot MB: https://www.tweaktown.com/news/59124/colorfuls-new-mining-motherboard-8-pcie... And here's a 4-port ssd adapter. https://www.amazon.com/Dell-Ultra-Speed-Drive-Quad-Adapter/dp/B0714MMD6M Fill up that MB with those adapters and you have 32 NVMe ports.

Impressive. Not sure the dimensions would work -- That adapter looks awfully wide. Unless they added more space on the MB, you'd be hard pressed to put in two of these in adjacent slots. But... where would I put the monitor and, extra network cards? Besides, I said you wouldn't put them on your X99 -- not a custom-designed board that would not fit in any current off-the-shelf case. So two years out you want to add another 24 drives, where do they go? I think my LSI controller supports up to 96 or 192 drives. I throw on another case & cable and can add another 24 drives. That's up to 240T using 10T drives.

And, who knows what the future will hold!

True enough. Sas+sata will become enterprise only -- probably priced out of consumer market, with consumer having no peripherals or hookups to allow importing or exporting content... :-/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Dec 14, 2017 at 8:00 AM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday, 2017-12-13 at 22:19 -0800, L A Walsh wrote:

...

...

And, who knows what the future will hold!

--- True enough. Sas+sata will become enterprise only -- probably priced out of consumer market, with consumer having no peripherals or hookups to allow importing or exporting content... : -/

No, I don't think that will happen. I think you will see both types of disks on the same machine. One internal for the system and home, others for large storage.

Then there is need for external storage.

Yes, but there are already MS Surface PCs with a NVMe drive internally and a single USB port. No exposed sata at all. In a few years I can easily envision motherboards for desktops with zero sata ports. I'm not saying good or bad about that. It's just reality that NVMe will replace sata for a lot of PC users in the next few years. As I said, I already see it routinely in my clients PCs. I've had my hands on about 15 client owned PCs in the last month. 3 had NVMe based primary storage (all laptops). Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2017-12-14 at 08:37 -0500, Greg Freemyer wrote:

On Thu, Dec 14, 2017 at 8:00 AM, Carlos E. R. <> wrote:

...

On Wednesday, 2017-12-13 at 22:19 -0800, L A Walsh wrote:

...

...

And, who knows what the future will hold!

--- True enough. Sas+sata will become enterprise only -- probably priced out of consumer market, with consumer having no peripherals or hookups to allow importing or exporting content... : -/

No, I don't think that will happen. I think you will see both types of disks on the same machine. One internal for the system and home, others for large storage.

Then there is need for external storage.

Yes, but there are already MS Surface PCs with a NVMe drive internally and a single USB port.

No exposed sata at all. In a few years I can easily envision motherboards for desktops with zero sata ports.

I'm not saying good or bad about that. It's just reality that NVMe will replace sata for a lot of PC users in the next few years. As I said, I already see it routinely in my clients PCs. I've had my hands on about 15 client owned PCs in the last month. 3 had NVMe based primary storage (all laptops).

Well, I have a minimal footprint machine, an MSI Cubi N, which can hold one laptop NVMe inside, or one laptop rotating disk, but the later needs a little chassis addon (included in packaging). No standard SATA or eSATA ports, but four USB3 ports, of which I use two for big external hard disks. I can imagine many laptops coming with NVME, yes, and a portion of those having no SATA bays. On desktop machines I have my doubts. Users needing lots of disk space will keep using rotating disks or plain SSDs, simply because of costs. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloyg8AACgkQtTMYHG2NR9VsnQCfVI84TLOmpNlo8te7Po2OtGPY v7sAn2zhS06TITPenBNH56KsivobW3iL =EIeY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Dec 14, 2017 at 10:24 AM, Per Jessen wrote:

Greg Freemyer wrote:

...

On Thu, Dec 14, 2017 at 8:00 AM, Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday, 2017-12-13 at 22:19 -0800, L A Walsh wrote:

...

...

And, who knows what the future will hold!

--- True enough. Sas+sata will become enterprise only -- probably priced out of consumer market, with consumer having no peripherals or hookups to allow importing or exporting content... : -/

No, I don't think that will happen. I think you will see both types of disks on the same machine. One internal for the system and home, others for large storage.

Then there is need for external storage.

Yes, but there are already MS Surface PCs with a NVMe drive internally and a single USB port.

No exposed sata at all. In a few years I can easily envision motherboards for desktops with zero sata ports.

Maybe just one for an optical drive?

Optical has already started to disappear. 50% or so of laptops already don't have it. I've built desktops without it. I use USB connected optical as often as not any more. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 13 December 2017 at 00:32, L A Walsh wrote:

PC's from ~7 years ago operated in the 4.8-6.4GT/s (Giga-transfers/s) and are now up to 10.4GT/s in current processors. That gives a comparison point to PCIe's 2.5 - 8 GT/s. That's likely to give around 2GB/s (I get up to a bit over 1GB/s with HW RAID using 7200RPM disks using a 3Gb/s bus speed (older generation computer). The random perf differences of the PCIe cf. my RAID, would likely be a few-to-several times greater than the linear.

So much faster (and maybe replacing conventional HD's for PC's, but w/RAIDs still used for capacity -- at least for a while.

My new home system has 2TB of NVMe storage and no HDD or SSD storage each NVMe is benchmarking at speeds of 3100GB/sec (read) and 2300GB/sec (write) That's 'Bytes', not 'bits' as typically used when benchmarking SATA/SAS drives. I could set them up as a RAID if I wished (AMD Bios' support it at least) So I don't think it's fair to categorise things the way you have. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2017-11-28 at 09:57 +0200, Dave Plater wrote:

On 27/11/2017 00:18, Mikhail Ramendik wrote:

Here's another possibility, I also have a system slowdown with swap, my single sata drive is quite slow due to the mb only having sata 2. I bought a 1T usb drive with usb 3 capabilities and then added a usb 3 adapter card. This gives me a much better transfer rate than sata 2 and just using a swapfile instead of my swap partition fixes the slowdowns. I would use it as for permanent swap partition except I left the microsoft partition and it now has to much important data to risk any repatrtitioning.

Yes, you about double the transfer speed, at least of big blocks. The problem is "fragmentation" which causes seeking and head movements, which are measured in milliseconds for rotating disks. On SSD there is no such issue. I use swap SSD on sata 2 and the speed advantage is huge. It would be better on sata 3, of course, or usb3. What I saw often on rotating rust was that the swaping speed was much lower than what the disk allowed, in theory. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlodeQMACgkQtTMYHG2NR9XZMgCeLKrs8uNN2gVgTuiXPCYzmBzG Jb0AmwXmDYVuoFnVo+pGx8JvbFQwdI05 =WQLn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org