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

[Stephen Hoffman]

On 2015-06-20 09:23:08 +0000, terry+googleblog at tmk.com said:

> The easy one is to write a utility that uses the operating system's 
> storage allocation map (BITMAP.SYS and friends on VMS) to construct a 
> free block list and (after appropriate sanity-checking) locks out I/O 
> to the disk from other processes and issues TRIM commands for those 
> blocks, then unlocks I/O. Many of the earlier SSDs for pre-TRIM systems 
> came with a "performance restoration utility" that did exactly this. 
> Most of the underlying OS functions you would need to write such a 
> utility exist on VMS - the "lock out all I/O except mine" exists in 
> ANALYZE/DISK/REPAIR, and I think the MOVEFILE primitive can be coerced 
> into marking blocks vacant and requesting TRIM.

Or an easier SMOP: just allocate a honking big file — say ~75% or ~90% 
of free space, depending on the variability of your storage usage — 
TRIM it all, then delete the file.  Repeat as necessary, on occasion.

> The better one is to have all of the necessary code between the 
> filesystem and the actual SSD device be TRIM-aware, so that a DELETE in 
> DCL, for example, makes it through the filesystem and down into the 
> disk driver with a list of blocks that are safe to TRIM. The big 
> problem here is that a number of "smart" controllers don't know what 
> TRIM is, and when the TRIM request gets added to the work queue of the 
> controller, the controller just ignores it (at best). This means that 
> controller and firmware vendors need to get involved. The best hope 
> here is for new VMS releases to use recent-vintage industry-standard 
> controllers which already know about TRIM, instead of older or obsolete 
> controllers with special DEC / Compaq / HP firmware, where HP would 
> have to pay for new firmware development in order to get the TRIM 
> support added.

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

As for older boxes, this isn't going to happen on pre-PCIe pre-SAS 
gear, as that's too slow for SSDs to matter.  That's Itanium prior to 
rx2660-era, and all Alpha boxes.  Those are all bus-limited.

As mentioned elsewhere, HP already supports their own SSDs on OpenVMS, 
and those have their own connections as well as what HP calls a "wear 
gage", so presumably some sort of TRIM-like support is present though 
apparently using HP proprietary connections.   The HP devices are also 
very expensive, but do work quite well.  (See link below for some 
related details.)

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

Related <https://laur.ie/blog/2015/06/ssds-a-gift-and-a-curse/>

-- 
Pure Personal Opinion | HoffmanLabs LLC