[Discuss] I need a recommendation for a Linux-compatible high-end PC builder

[Alan W. Irwin]

On 2018-01-27 21:28-0800 Cy Schubert wrote:

> In message <0D45725C-AAF0-4164-9833-65824155FB6E at gmail.com>, Jean
> Taggart write
> s:
>> Hello Alan,
>>
>> Splurge for an ssd.
>>
>> Most modern ones do trim and wear leveling at the controller level.
>
> Only if the filesystem support trim. You must enable this. On my
> FreeBSD systems it's a tunefs option. ZFS automatically detects SSD and
> enables it. On Linux ext4, for example, you would use the discard
> option.
>
>>
>> Ssd’s have provided the most performance differences in all my recent builds.
>>  The whole premature wear fears have been addressed. 1tb ssd for the os, 4tb
>> for data as  2nd drive.
>
> The wear is due to electrons passing through a gate.
>
> It's best to use your ssd for primarily read such as /, /boot, /usr, or
> /opt, unless you update your system a lot or use it for O/S development
> (like I do) but not for /var, /tmp, or swap.
>
> Having said that a lot of accesses will also wear out a disk actuator
> too.
>
>>
>> I have 10 systems that run Ubuntu and Debian on ssd’s used for work, intense
>> testing. So far only one failure. I’m an early adopter and that was a Samsung
>>  evo 950.
>
> My wife's laptop has had one fail with no warning though the technology
> was young then. Today's SSDs use microprocessors to distribute writes
> across the SSD, maintaining a map of logical to physical blocks.
>
>>
>> I can’t recommend them enough.
>
> My work laptop has one. The performance gain is very noticeable.

To Cy and Jean:

Typically every new system has a speed gain compared to older systems
because of faster cpu's, faster memory, faster HDD throughput, etc. So
did you actually measure that SSD gave you any advantage by copying
your system from SSD to HDD and comparing speeds between HDD alone and
SSD + HDD for the same system and same hardware?

The reason I ask how you are measuring these speed gains is I just
don't get for large RAM systems why there is any major speed gain at all
from an SSD that is dedicated to system files (with the exclusions you
mentioned above to keep the write wear down).  The size of the "/"
partition on my current system is "only" 18G.  Let's make the
ridiculous assumption that all those files are actually used (rather
than just there in case of need which is likely true for the vast
majority of them). Then if you had large amounts of RAM
(such as the 64GB I am about to buy) Linux would automatically cache
all those files in RAM to give you essentially instantaneous access to
them.  So on large RAM systems the SSD would speed up access to the
system files the first time you used them after a boot, but then after
that the SSD would never be used again for that file until the next
boot.  Of course, I am making the assumption here that most system
files are only read and not written, but an attempt is made with SSD's
to exclude the parts of the "/" partitition that are written in any
case so I don't think this can be an important argument against this
interpretation.

The above mental model jibes with my own practical experience which is
for a system with "only" 4GB of RAM, I do get what I call "morning
sickness".  That is overnight jobs (the normal ones and also an
additional one in my case that builds and tests CMake and PLplot on a
nightly basis) completely exhaust the cache of files that Linux keeps
in RAM (and the disk cache that is part of the HDD hardware) so the
initial access by me each day tends to be slow.  But from then on that
day, the relevant file is cached in RAM so access is quick for a
system without an SSD.  What I am arguing above is for RAM large
enough, this morning sickness would go completely away (because the
overnight tasks would not exhaust the RAM cache), and be turned into
"boot sickness".  And I just don't think the complexity (e.g., special
configuration measures required to avoid writes) and cost of SSD's is
justified just to reduce (not remove) morning sickness, and the
argument becomes even stronger if an SSD is only going to reduce boot
sickness.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________