[Info-vax] How do I assign a disk to a CPU?

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Sun Oct 18 11:22:45 EDT 2020


On 2020-10-18 10:06:57 +0000, seasoned_geek said:

> On Friday, October 16, 2020 at 11:03:58 AM UTC-5, Stephen Hoffman wrote:
>> 
>> And if still on HDDs while pondering permuting preferred path, promote 
>> pondering SSDs too. FC SAN Storage Controllers are fast, but HDDs are 
>> HDDs and slow and there's only so much cache.
> In the PC world that hasn't exactly been my experience. SSDs are very 
> fast with READ operations but duth sucketh with WRITE operations. They 
> mask this with cache. When you are doing massive write operations, you 
> need a spinning disk.
> ...and several different Samsung 840 series SSDs the build time 
> difference was about an hour...

If this was ~five years ago or so, and/or with under-revision storage...

Samsung 840 Pro purportedly had a firmware TRIM bug in then-common 
firmware versions. Asynchronous TRIM would delete random data. Linux 
worked around that corruption by disabling asynchronous TRIM. Which'd 
throttle write performance, causing the observed write behavior.

Samsung released firmware fixes for 840 Pro, 850 Pro, and other 
effected devices some years ago.

Among various discussions of this firmware bug from back then: 
http://forum.notebookreview.com/threads/major-trim-bug-found-in-samsung-ssds-limited-to-linux.777427/ 


> Some day I will experiment with a hybrid drive.

Unimpressed with the Apple Fusion hybrid drives; HDDs with a 
variable-size flash cache. The performance is better than HDD on 
average, though apps can end up running at HDD speeds if (or when?) the 
cache mis-predicts.

Errata...

Smaller caching best needs to be cognizant of system and app activity 
(XFC, etc), where simpler caching further down the I/O hardware stack 
can't be and can trade off cache sizing (hopefully) for performance 
increases. All designs have trade-offs and compromises.

With contemporaneous server and app and storage designs and with 
contemporaneous pricing, HDDs tend to best be used for archival 
storage. When you need big pools of storage, and aren't in a hurry to 
access it; fast nearline, or backup, or archival storage.
DVD, HDD, and other storage firmware has also had issues. There were 
well-known-vendor-branded optical drives that sometimes mis-recorded 
data, as verified with OpenVMS and a patched DQDRIVER. And OpenVMS 
itself has shipped with firmware maintenance tools for updating storage 
firmware.

There's the whole discussion of how VSI OpenVMS will be auditing 
firmware and how customers will be loading new vendor firmware with the 
OpenVMS x86-64 port, too. Firmware is ubiquitous, residing within 
processors, management processors, storage, NICs, and ~everything else. 
Server maintenance starts out problematic, and the mess increases as 
the numbers of servers in use increases.

The OpenVMS servers configured with SSD storage are stonking fast, and 
the configurations have been at least as stable and reliable as HDDs. 
And did I mention stonking fast I/O?



-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list