[PLUG-TALK] SSHD accelerated drives Re: SSD lstat ...

[Denis Heidtmann]

On Sun, Nov 27, 2016 at 1:49 PM, Keith Lofstrom <keithl at kl-ic.com> wrote:

> On a slightly different subject, rotating magnetic disk
> hard drives with substantial solid state "caches" are
> far less expensive than pure solid state drives.  I'm
> about to deploy a Seagate ST1000LM014 laptop drive, with
> 1000 GB of disk and 8 GB of NAND flash.  Supposedly,
> the drive uses the NAND flash as a cache for frequently
> read sectors.
>
> I have no idea how well it will perform with Linux;
> perhaps it is incompatible, or optimized for Windows,
> or optimized for new versions of Windows designed to
> work with such drives.
>
> I will deploy it with a clone of Red Hat Enterprise
> Linux version 7 (3.10 kernel) on an older laptop.
> Specifically, I will first get the distro working on
> an older 500 GB traditional drive, then copy that
> working image to a 1000 GB Seagate for the same laptop.
>
> SO, THE QUESTION FOR THE LIST, which may have some
> relevance to the SSD lstat question; how do I perform
> an objective before-and-after test of the usability
> and speed, beyond boot time?  What simple tests would
> you folks like me to do?
>
> My personal interest is reliability, not speed.  Hard
> disks fail because moving parts wear out; the fewer head
> accesses I make to the platter, the better.  OTOH, solid
> state drives tend to fail because the write process
> involves higher voltages, which wears out the electronics.
> Solid state read access can be very fast, yet involve
> less stress than swinging heads across a rotating platter
> for read or write, and both of those less than a solid
> state write operation.
>
> If the drive is versatile enough to optimize the SS as
> a cache for frequently accessed sectors for LINUX, this
> is a win-win.  On the other hand, if the drive does not
> accomodate the way Linux uses a disk, it could be a big
> disappointment.  On the third hand, a Linux file system
> optimized for these drives might be superhigh performance.
> On the fourth hand, these drives are new and their
> behavior will evolve, so a file system optimized for a
> 2016 SSHD drive might be terrible for a 2018 SSHD drive.
>
> I have a 50% deficit of hands here, so I could use a
> hand or five from the rest of you.  What should I test?
> Send code (compilable or RPM), not vague suggestions for
> tests I have no clue how to code or perform.  Thanks!
>
> Keith
>
> --
> Keith Lofstrom          keithl at keithl.co <keithl at keithl.com>m


Is there a chance that any of the designers of the Linux file system(s)
could contribute some knowledge to the question you pose?  I have no idea
how or to whom to address the questions, but someone should know.  In other
words, go to the horse.

-Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pdxlinux.org/pipermail/plug-talk/attachments/20161127/a553dad4/attachment.html>