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

[Stephen Hoffman]

On 2015-06-25 17:19:55 +0000, Michael Moroney said:

> I am not familiar with TRIM beyond what people have written here, but
> VMS already has an IO$_DSE function...

FWIW... DSE writes are unnecessary on any recent SSD, as — like the old 
DSSI drives of yesteryear — most any recent SSD drives include an 
secure erase command.

Additionally, SSDs now also often include drive encryption, though 
OpenVMS presently has no clue what to do with encryption on either HDD 
or SSD storage.

For a pattern overwrite, DSE causes a data write — the "rewrite" here 
would first require a data erase on the target SSD sector(s) and then a 
write, a combination which is really slow — and which will usually mean 
the SSD drive will reallocate new storage and remap the address as part 
of SSD wear leveling, which means that the old SSD data is not erased, 
and which means that the new overwrite is also just unnecessary disk 
wear.

It's the file delete or the block deallocation operation that's the 
appropriate trigger for TRIM.  Particularly given it is possible to use 
DSE on a file without deleting it.    TRIM itself is slow, so — in the 
absence of the queued variant of the TRIM command that's become 
available — OpenVMS would probably want to scrub the data periodically, 
as (most!) users probably won't want to wait for the completion.

Multipass DSE is questionable on most devices, too.  Generic erase via 
security erase command followed by slagging the disks is more typical, 
for those sites with sufficiently strict security requirements.  
Between the SSD data remanence, and the potential for HDD remanence 
from disk errors and revectored sectors...  Slag it.

Adding a check for support and then a secure erase request to an 
INITIALIZE /ERASE would be reasonable, too.

For best security, keep the drive encrypted — yes, even a fixed-media, 
server-room HDD — and use the drive secure erase operation when you're 
done.  Then slag the disk.

Then there's the whole discussion of support for and handling of PCIe 
flash and inboard storage and such.   Emulating an HDD and using its 
existing I/O interface is nice for now, but storage is moving inboard 
and away from the HDD I/O interface.

-- 
Pure Personal Opinion | HoffmanLabs LLC