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

terry+googleblog at tmk.com terry+googleblog at tmk.com
Mon Jun 22 03:52:26 EDT 2015


On Sunday, June 21, 2015 at 11:28:18 AM UTC-4, Stephen Hoffman wrote:
> 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.

Yup, but that was mostly because they discovered "artifacts" of controller chips they'd been using for some time (CMD ATA, for example) and adding a check was easier and cheaper than replacing hardware in the field.

That's more recent than DEC intentionally introducing non-standard breakage (if you want to be disgusted, look at the way the RQDX3 firmware tells the difference between an RD53 and an RD54). That was "The Digital Difference".

> 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.

Yup, I didn't want to get into that either. I didn't come here for an argument (about that, at least 8-).

> 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.

I did, and I wonder how some of those people / systems got qualified as enterprise systems. A lot of what they are complaining about (but not all) can be described as "We bought a HP / Dell / whatever server with a proprietary RAID controller, went to the corner computer store and bought some consumer SSDs and hooked them up in RAID, and weird things happened". No kidding! Weird things will happen if you try using generic spinning rust drives on OEM RAID controllers instead of that OEM's "special" drive firmware. Oddly, a lot of those things _don't_ happen if your reflash the OEM RAID controller to the generic controller manufacturer's firmware.

Yes, they ran into some weird behavior on manufacturer-certified configurations, but they seemed generally happy as to the speed and method of resolution in those cases.



More information about the Info-vax mailing list