In the early days of SSDs, there was a lot of talk in the Linux community that you shouldn't have a swap partition on an SSD. An indirect side effect of that is that it becomes impossible to suspend-to-disk (aka "hibernate") on a SSD-only system. Although I suppose that you could have the swap partition and set swappiness to 0. So I have a new SSD system, and was wondering the current state of these things: - is it considered okay to have a swap partition on an SSD drive? - how should I set the swappiness? - is it considered okay to hibernate to an SSD? -- Giles https://www.gilesorr.com/ gilesorr@gmail.com
On January 27, 2018 8:49:15 AM EST, Giles Orr via talk <talk@gtalug.org> wrote:
In the early days of SSDs, there was a lot of talk in the Linux community that you shouldn't have a swap partition on an SSD. An indirect side effect of that is that it becomes impossible to suspend-to-disk (aka "hibernate") on a SSD-only system. Although I suppose that you could have the swap partition and set swappiness to 0. So I have a new SSD system, and was wondering the current state of these things:
I'm still tweaking/breaking (in) my new SSD desktop system myself. I took Hugh's advice and did some research on TRIM. This link has lots of info. https://wiki.debian.org/SSDOptimization My observations so far.
- is it considered okay to have a swap partition on an SSD drive?
Yes, it's getting to be an inevitability. The key is to optimize the system to minimize the number of writes. ie. config w/ noatime to reduce writing all of the files access times to the drive. Some questions around that tho. Later kernels use relatime as a default middle ground. Kernels 4+ have lazyatime available. https://lwn.net/Articles/621046/
- how should I set the swappiness?
That all depends on the operational stress factors. I think that on an average desktop, the default is fine. https://lwn.net/Articles/83588/
- is it considered okay to hibernate to an SSD?
Just from what I've read so far, if you keep to the convention of 2x(ram) for the swap you shouldn't have any problems.
Again, from what I've read recently, the general feeling is that an enterprise SSD, capable of >50gb writes in a day, is as virtually stable as a standard HDD. Consumer SSD's are considered the same if writes =<20gb a day. HTH
-- Giles https://www.gilesorr.com/ gilesorr@gmail.com
-- Russell
| From: Giles Orr via talk <talk@gtalug.org> | In the early days of SSDs, there was a lot of talk in the Linux community | that you shouldn't have a swap partition on an SSD. An indirect side | effect of that is that it becomes impossible to suspend-to-disk (aka | "hibernate") on a SSD-only system. I don't even know how to ask to hybernate these days. I last did it in the APM days. How do you do it? I have one perverse system that it would be useful for. | - is it considered okay to have a swap partition on an SSD drive? Yes. | - how should I set the swappiness? I don't know. | - is it considered okay to hibernate to an SSD? Yes. Russell's message is probably a better source than what I'm going to say. - the key to SSD longevity is to keep writes to a reasonable amount - the hard-to-understand factor is "write amplification" - write amplification, roughly, is that a small write on to the disk, from the software's standpoint, causes a lot of writing to the actual flash memory. - The model of hard disk we and Linux have is simulated by the SSD because flash isn't really like a hard disk. - write amplification gets really bad as the flash gets full. - Trimming allows the flash firmware to know when virtual disk blocks are no longer needed. This is important. Otherwise, the only way it knows is if the virtual disk block is rewritten -- then the old value and its space are vacated. But rewriting of a block also ties up a new chunk of flash for the new value of the block. On trimming can reduce the number of blocks allocated. - trimming is mostly used to advise the SSD firmware that the blocks of a deleted file are no longer needed. It is also used (I hope and assume) when you mkfs or repartition. - the other (complementary) way of reducing fullness is to actually leave unused space on your filesystems. Unused Space in any filesystem on a device reduces write amplification for all filesystems -- it is a global property of the device. You can also do this by not allocating the whole virtual drive to partitions. - All flash drives have some more flash than the virtual drive presents. This is called "over provisioning". Enterprise drives have more. - write-amplification, as a function of the amount of free flash, is quite non-linear ("hockey stick curve"). So it is critical not to get to 100% full (you cannot, due to over provisioning), but below some threshold (95%???) and things are fine.
On 2018-01-27 08:49 AM, Giles Orr via talk wrote:
In the early days of SSDs, there was a lot of talk in the Linux community that you shouldn't have a swap partition on an SSD.
In the early days of SSDs the main thing I was hearing about was that you should turn off writing of atime. I don't know if that is still the case or not. -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful!" #include <disclaimer/favourite> | --Chris Hardwick
participants (4)
-
D. Hugh Redelmeier -
Giles Orr -
Kevin Cozens -
Russell