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

[Dirk Munk]

Stephen Hoffman wrote:
> 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

I get this, but the question is if the drive itself is generating this 
data, or that VMS is sending that data to the drive.

If IO$DSE triggers an HDD to write data to erase a block  by generating 
and (re)writing data, then the same IO$DSE could trigger an SSD to erase 
a block the SSD way. In both cases the data gets erased, but in a 
different way.

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

Sure, but this can only occur when VMS is sending data, and that's not 
what we intend.

>
> It's the file delete or the block deallocation operation that's the
> appropriate trigger for TRIM.

I agree

> Particularly given it is possible to use
> DSE on a file without deleting it.

 > If we assume that DSE could trigger TRIM, then you couldn't use DSE 
for this purpose on an SSD.

> TRIM itself is slow, so — in the
> absence of the queued variant of the TRIM command that's become
> available

Isn't the queued variant the 'standard' variant of TRIM we would like to 
see, and isn't it the standard variant on Windows and Linux for instance?

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

Very true, and that was my first thought when I read about STEC SSD's 
years ago. Very nice to put flash in a disk container behind a disk 
interface, but only as long as we haven't got a proper interface.