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

[Stephen Hoffman]

On 2015-06-25 22:27:02 +0000, Dirk Munk said:

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

There is no "VMS sends the data" case for an HDD-style block erasure 
operation here.   Not for SSD erasure.  Not short of rewriting all of 
the drive and then some.  Maybe not even then, if some sector got set 
aside.

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

Ayup.  Though DSE and its erasure and TRIM and its erasure are 
orthogonal.    TRIM is part of making SSD allocations faster, by 
returning unallocated blocks into a pool of storage that can be erased 
at the SSD firmware level and made available for new storage 
allocations and remapped anywhere in the SSD block address space.  DSE 
is intended to make sure that the data in the block is gone.

DSE does not mean that the file itself is deleted and that the storage 
is now available.

DSE just (tries to) overwrite the target blocks with zeros or with the 
output of $erapat calls.  This host-based overwriting is not feasible 
on SSD, hence my pointer to SSD-level encryption.

f you aim a TRIM command at a file as part of a DSE that's not also 
part of a deallocation operation, then somebody's potentially going to 
have a Very Bad Time.

Rather than TRIM, a DSE would want to send a secure erase command, if 
that's available, and you'd usually want the data erased before the 
command completes.   This secure erasure is similar to what happens on 
some of the older MSCP widgets; those devices that had a firmware-level 
erase command, and VMS just triggered that.   The file delete or block 
deallocation would send the TRIM (possibly "eventually", not 
immediately) or queued TRIM, and implicit in that is (hopefully) a 
block-level erasure that's also implicit in the TRIM.  Eventually.

Clear as mud, no?

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

Variant or not, the SSD has to support the commands used.   Queued TRIM 
is part of a newer version of the T13 docs than the older ATA TRIM 
command.   (I'm not entirely certain that the final version with the 
queued TRIM has actually been published yet, either — haven't read the 
current T13 docs.)


-- 
Pure Personal Opinion | HoffmanLabs LLC