<div dir="ltr">>> <span style="font-size:12.8px">Typically every new system has a speed gain compared to older systems</span><br style="font-size:12.8px">>> <span style="font-size:12.8px">because of faster cpu's, faster memory, faster HDD throughput, etc. So</span><br style="font-size:12.8px">>> <span style="font-size:12.8px">did you actually measure that SSD gave you any advantage by copying</span><br style="font-size:12.8px">>> <span style="font-size:12.8px">your system from SSD to HDD and comparing speeds between HDD alone and</span><br style="font-size:12.8px">>> <span style="font-size:12.8px">SSD + HDD for the same system and same hardware?</span><div><br></div><div><div>For my main home laptop (which I'm writing this email on) it's had a Samsung Evo SSD in it for about 2 years now as the only drive. I've had zero issues with it, and the performance difference was night and day going from the original drive. Originally it had a spinning disk in it (TBF, I *think* it was only a 5400 RPM drive, so not the best of spinning disk technology), but in terms of "single change upgrades" going from the spinning disk to SSD on this thing is probably the biggest single improvement I've seen in a machine I've owned (not just load times, but general responsiveness). Before the SSD I was ready to buy a new machine because it was so slow, and after the SSD I've been completely happy with the machine and it's the only thing I've replaced/changed on it.</div><div><br></div><div>Full disclosure: it's not a Linux-based system (Macbook), and is an "average", day-to-day use laptop (so not "dream" machine by any stretch, only 4GB of RAM & an I5 processor).</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 28, 2018 at 12:17 PM, Alan W. Irwin <span dir="ltr"><<a href="mailto:irwin@beluga.phys.uvic.ca" target="_blank">irwin@beluga.phys.uvic.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2018-01-27 21:28-0800 Cy Schubert wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In message <<a href="mailto:0D45725C-AAF0-4164-9833-65824155FB6E@gmail.com" target="_blank">0D45725C-AAF0-4164-9833-65824<wbr>155FB6E@gmail.com</a>>, Jean<br>
Taggart write<br>
s:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Alan,<br>
<br>
Splurge for an ssd.<br>
<br>
Most modern ones do trim and wear leveling at the controller level.<br>
</blockquote>
<br>
Only if the filesystem support trim. You must enable this. On my<br>
FreeBSD systems it's a tunefs option. ZFS automatically detects SSD and<br>
enables it. On Linux ext4, for example, you would use the discard<br>
option.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ssd\u2019s have provided the most performance differences in all my recent builds.<br>
The whole premature wear fears have been addressed. 1tb ssd for the os, 4tb<br>
for data as 2nd drive.<br>
</blockquote>
<br>
The wear is due to electrons passing through a gate.<br>
<br>
It's best to use your ssd for primarily read such as /, /boot, /usr, or<br>
/opt, unless you update your system a lot or use it for O/S development<br>
(like I do) but not for /var, /tmp, or swap.<br>
<br>
Having said that a lot of accesses will also wear out a disk actuator<br>
too.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have 10 systems that run Ubuntu and Debian on ssd\u2019s used for work, intense<br>
testing. So far only one failure. I\u2019m an early adopter and that was a Samsung<br>
evo 950.<br>
</blockquote>
<br>
My wife's laptop has had one fail with no warning though the technology<br>
was young then. Today's SSDs use microprocessors to distribute writes<br>
across the SSD, maintaining a map of logical to physical blocks.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I can\u2019t recommend them enough.<br>
</blockquote>
<br>
My work laptop has one. The performance gain is very noticeable.<br>
</blockquote>
<br></div></div>
To Cy and Jean:<br>
<br>
Typically every new system has a speed gain compared to older systems<br>
because of faster cpu's, faster memory, faster HDD throughput, etc. So<br>
did you actually measure that SSD gave you any advantage by copying<br>
your system from SSD to HDD and comparing speeds between HDD alone and<br>
SSD + HDD for the same system and same hardware?<br>
<br>
The reason I ask how you are measuring these speed gains is I just<br>
don't get for large RAM systems why there is any major speed gain at all<br>
from an SSD that is dedicated to system files (with the exclusions you<br>
mentioned above to keep the write wear down). The size of the "/"<br>
partition on my current system is "only" 18G. Let's make the<br>
ridiculous assumption that all those files are actually used (rather<br>
than just there in case of need which is likely true for the vast<br>
majority of them). Then if you had large amounts of RAM<br>
(such as the 64GB I am about to buy) Linux would automatically cache<br>
all those files in RAM to give you essentially instantaneous access to<br>
them. So on large RAM systems the SSD would speed up access to the<br>
system files the first time you used them after a boot, but then after<br>
that the SSD would never be used again for that file until the next<br>
boot. Of course, I am making the assumption here that most system<br>
files are only read and not written, but an attempt is made with SSD's<br>
to exclude the parts of the "/" partitition that are written in any<br>
case so I don't think this can be an important argument against this<br>
interpretation.<br>
<br>
The above mental model jibes with my own practical experience which is<br>
for a system with "only" 4GB of RAM, I do get what I call "morning<br>
sickness". That is overnight jobs (the normal ones and also an<br>
additional one in my case that builds and tests CMake and PLplot on a<br>
nightly basis) completely exhaust the cache of files that Linux keeps<br>
in RAM (and the disk cache that is part of the HDD hardware) so the<br>
initial access by me each day tends to be slow. But from then on that<br>
day, the relevant file is cached in RAM so access is quick for a<br>
system without an SSD. What I am arguing above is for RAM large<br>
enough, this morning sickness would go completely away (because the<br>
overnight tasks would not exhaust the RAM cache), and be turned into<br>
"boot sickness". And I just don't think the complexity (e.g., special<br>
configuration measures required to avoid writes) and cost of SSD's is<br>
justified just to reduce (not remove) morning sickness, and the<br>
argument becomes even stronger if an SSD is only going to reduce boot<br>
sickness.<div class="HOEnZb"><div class="h5"><br>
<br>
Alan<br>
__________________________<br>
Alan W. Irwin<br>
<br>
Astronomical research affiliation with Department of Physics and Astronomy,<br>
University of Victoria (<a href="http://astrowww.phys.uvic.ca" rel="noreferrer" target="_blank">astrowww.phys.uvic.ca</a>).<br>
<br>
Programming affiliations with the FreeEOS equation-of-state<br>
implementation for stellar interiors (<a href="http://freeeos.sf.net" rel="noreferrer" target="_blank">freeeos.sf.net</a>); the Time<br>
Ephemerides project (<a href="http://timeephem.sf.net" rel="noreferrer" target="_blank">timeephem.sf.net</a>); PLplot scientific plotting<br>
software package (<a href="http://plplot.sf.net" rel="noreferrer" target="_blank">plplot.sf.net</a>); the libLASi project<br>
(<a href="http://unifont.org/lasi" rel="noreferrer" target="_blank">unifont.org/lasi</a>); the Loads of Linux Links project (<a href="http://loll.sf.net" rel="noreferrer" target="_blank">loll.sf.net</a>);<br>
and the Linux Brochure Project (<a href="http://lbproject.sf.net" rel="noreferrer" target="_blank">lbproject.sf.net</a>).<br>
__________________________<br>
<br>
Linux-powered Science<br>
__________________________<br>
<br>
______________________________<wbr>_________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@vlug.org" target="_blank">Discuss@vlug.org</a><br>
<a href="http://vlug.org/mailman/listinfo/discuss_vlug.org" rel="noreferrer" target="_blank">http://vlug.org/mailman/listin<wbr>fo/discuss_vlug.org</a><br>
</div></div></blockquote></div><br></div>