[Info-vax] VMS and the (lack of the) TRIM facility.

[Stephen Hoffman]

On 2015-06-21 04:46:26 +0000, terry+googleblog at tmk.com said:

> On Saturday, June 20, 2015 at 11:36:22 AM UTC-4, Stephen Hoffman wrote:
>> That's XQP-level, and VMS would need to flag those controllers that had 
>> TRIM, as well as then issuing the TRIM request for the erasure or the 
>> deletion.   OpenVMS already has something similar.  (See below.)
> 
> It should be perfectly fine to always pass that info down to the 
> appropriate driver. The driver can then simply discard the trim request 
> (returning successful completion) if none of the devices it talks to 
> supports TRIM, or it can pass the request along to a device if that 
> device is known to support TRIM.

Of course that's with modified drivers, and not with the diagnose 
interface, and very likely not with the HP SSD interface that's already 
available.   Need SSDs now?  Use the HP SSDs.

> Drives that support TRIM can be queried for that status, and give the 
> nature of VMS device support (if it isn't on the SPD, it isn't 
> supported even if it might work), dealing with devices that get wrong 
> is less of an issue than on Linux, Windows, etc. which usually maintain 
> a list of devices with quirks in order to handle them differently.

In years past, OpenVMS device drivers maintain (very messy) lists of 
quirks as in-line code, usually with comments, and OpenVMS never got 
around to having any particular list of or database of those quirks.   
For rather fewer devices than Linux and Windows support, too.

All of which raises a most excellent detail, too: with the explosion of 
hardware available on x86-64, OpenVMS will probably eventually end up 
adding a list of quirks or options or knobs, and the existing OpenVMS 
device database files would be the obvious spot to add those.  The 
existing supported configuration SPD model is has been entirely 
untenable for device support for years, and which means VSI is heading 
toward something akin to HP SPOCK, or — probably saner — moving that 
support data into a device database file that's viewable on the web 
site and also located on OpenVMS itself and that gets updated on 
OpenVMS.

> On other operating systems the overhead of getting the TRIM requests 
> all the way down to the driver level is miniscule, and I don't see that 
> VMS would be different.

The overhead of the $qio[w] or of $io_perform[w] or ALTSTART is likely 
just an extra trip through the I/O stack with the TRIM request and a 
list of blocks, at most.   OpenVMS also needs a whole lot of work to 
bring its I/O stack up to the speeds of some of the Linux driver 
stacks, but I digress.

The implementation is entirely feasible, though the effort will 
probably be slightly less than miniscule.   It's just code changes, and 
driver code changes, and XQP code changes, and driver code changes on 
some comparatively hairy devices that are sometimes known to not deal 
with TRIM at all well and variously toss your data into the Ether, and 
that was not something that DEC and Compaq and HP were fond of.   And 
testing and qualification.  And of course the inevitable costs of 
support.   This if the existing HP SSD support is not generic, and I'd 
suspect it's not.

Support and testing has some cost.   The 48-bit IDE ATA addressing 
support changes I was using locally were quite reasonably shut down as 
an OpenVMS enhancement, as an example.  Testing those changes would 
have taken a whole lot of time and effort across all of the supported 
devices and configurations and servers, and some of those IDE 
controllers and those devices were known to go catatonic when presented 
with unrecognized commands.   Unrecognized commands, and not 
necessarily invalid commands.   At the time, there were a lot of 
devices supported, too.

Yes, we're thankfully well past IDE and along to the era of SAS, SATA, 
mSATA and M.2 widgets, and to whatever PCIe or Thunderbolt is hooked 
to, but widgets can and do still have bugs, which means VSI will be 
testing what they plan to support.   (M.2 is already used in some HP 
Moonshot ProLiant configurations.  Whether it becomes more commonly 
encountered with servers?)

Hopefully VSI can and will get a roadmap going and can chuck out 
support for some of the older devices and older servers, and then chuck 
out the older code and workarounds, too.

>> Generic TRIM support can sometimes be dicy, as some controllers and 
>> some SSDs don't do that very well and there have been cases of data 
>> loss.  In short, it'd probably be on approved controllers by default, 
>> and enabled by site-specific override on others.  (See link below.)
> 
> SSDs have gotten a lot better since they were introduced.

Read the link <https://laur.ie/blog/2015/06/ssds-a-gift-and-a-curse/> — 
yes, device support is getting better in general, but is still a 
morass, and the OpenVMS crowd is still very fond of getting their data 
back from whatever it was written to.

Apple has gotten around to adding TRIM with their upcoming release, and 
reportedly with the following message: "This tool force-enables TRIM 
for all relevant attached devices, even though they have not been 
validated for data integrity while using that functionality. By using 
this tool to enable TRIM, you agree that Apple is not liable for any 
consequences that may result, including but not limited to data loss or 
corruption."

Do I think that TRIM should be available?  Yes.  Do I think it'll be 
simple or quick or possibly even ever available on Itanium — other than 
the existing HP SSDs — at all?  No.

VSI can and should and will undoubtedly make their own decisions here.  
Whether TRIM and VSI "SPOCK" and/or SYS$CONFIG.DAT, SYS$USER_CONFIG.DAT 
and/or SYS$UCM_DEVICES.DAT is part of that, I don't know.  I'd tend to 
assume they'll keep most of their engineering staff on the port, though.

FWIW / ps: SPOCK or not, the OpenVMS support documentation and support 
status for the p411 and p812 widgets is... tangled.


-- 
Pure Personal Opinion | HoffmanLabs LLC