[TriLUG] SWAP and SSD vs HDD

[Ken MacKenzie]

First off all thank you for all the great responses.  This group rocks and
I learned a lot more especially from this last post about the hardware
architecture of current gen drives.

To wrap up I felt that it really didn't matter all that much, it was a
slight teeter between drive life and performance and it was ever so
slight.  It also seemed that in the end the gains in performance might
outweigh the loss in drive life in either is even noticeable.

So I elected with all that information to go with what I felt was "logical'.

The SSD will hold all "OS" partitions and the "HDD" will receive all data
partitions.  A better divide IMO and since the host isn't exactly a server
and true server functions will be handled by VMs under the host (this is a
home computer after all) that /var would also go on the SSD with SWAP.  It
just made more sense and the drive I care about not dying really is the HDD
because it is a data store I wish to persist and backup.

So the HDD will get /home and some other "home" like partitions I created.

Again thank you for all the awesome input.

Ken

On Thu, Nov 6, 2014 at 3:01 PM, Don Jerman <djerman at pobox.com> wrote:

> Ah basic information - I've just been reading on this:
>
> Most SSD are built on flash memory cells, which yes, have a limited number
> of writes depending on the details of their construction.  There are 2 or 3
> methods in use which get faster at the expense of durability - single-level
> cells give around 100000 writes, mostly used in usb keys and the like.
> Multilevel cells get about 10000 and triple level cells only about 2000, or
> so it's said (they're new-ish).
>
> Virtually all flash storage devices have a firmware layer that maps
> physical cells into blocks to seem like regular block storage devices, and
> it applies a wear-leveling scheme to prevent all the writes going to the
> same set of cells even if you write the same logical block over and over
> (like touching a lock file and updating its metadata). Most will also move
> "long-static" blocks around to wear out those cells too (so that archived
> video file doesn't lock away all the "fresh" cells).  The same firmware
> applies error correction and silently detects failed cells to be mapped out
> of the drive's available space (unless there's an ioctl to inquire about
> that, then it's not entirely silent).  Most devices are over-provisioned
> (amounts vary) so the first failed blocks aren't visible in terms of
> capacity reduction, and the device can do some signalling when cells start
> to fail.  And since they're wear-leveled, by the time the overage starts
> getting used up all the cells will be near failure.  This also means they
> tend to fail all-at-once, so don't put anything there that isn't backed up
> somewhere else.
>
> So for a 160GB drive with TLC (worst-case) you'd expect to write 320TB
> (maybe more) to it before you break down, but you're not getting your hands
> on one of those - yours will probably be multi-level which should be good
> for about 1.6 petabytes of writing.  Even at SSD speed that should take a
> long time - probably long enough for you to be upgrading your system a
> couple of times for other reasons.
>
> In a server situation you should probably mirror all SSDs and stagger the
> mirror with shelf spares to reduce the chance of simultaneous failure (that
> is, replace the odd members of all pairs after about 1/4 of expected
> service life, so that the fresh one you swap in will carry the mirror when
> the older one fails - you can use the 1/4 used ones as replacements when
> that happens).
>
> Turning back to the topic, swap reads are typically low priority, and SSD
> writes are typically not as much faster than HD writes as to make a
> difference in a situation where you're utilizing all your RAM.  SSD reads
> are fast but typically swapping involves low-priority dirty blocks so you
> won't notice that much unless you've got bigger problems with working set
> management - probably better addressed by fixing programs than fixing
> hardware.
>
> So I haven't run a linux laptop in a few years - is is possible to specify
> a hibernation file path separately from swap?  That would be cool with an
> SSD - just use it for OS files and sleeping.
>
>
>