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

[JF Mezei]

On 15-06-25 15:42, Michael Moroney wrote:

> The IO function IO$_DSE is intended to erase data by overwriting it with
> a pattern (or multiple patterns for use by three letter agencies).

TRIM command on an individual block can only mark it as "unused". It
cannot write to it or modifying it as doing so would defeat the purpose
(the SSD would then copy the whole page to a new page, replacing the
modified block with 0s.)

Also, the TRIM command, if all it does is mark the block as
erasable/unusued would keep the data on the block and thus be available
for an undelete operation. (theoretically).

So using the "zero on delete" function of VMS would not be proper as it
not only woudl require modification of a block (causing write
amplification problem) but also make "undelete" operations impossible.

Now, if VMS were to use a virtual bock size that matches the SSDs' page
size, then many aspects of SSDs might become more interesting since the
SSD would then have its ability to erase pages match VMS's writing of
data in units that are exactlyt the same size as a page.

Conceptually, allows the SSDs to rewrite over the same page every time
since it can zap the page, and write modified page over it. (but this
defeats the write leveling logic that spread writes to all the pages for
even wear of the SSD).

You would want VMS to have a new separate item code to mark block as
unused and such item code would be acted upon by the driver when the
target device is an SSD with TRIM enabled.

This would have some performance aspect since when deleted a highly
fragmented file, $DELETE would have to issue TRIM IO commands for every
fragment of the file (I would assume the IO request for TRIM would allow
for range of blocks to be specified, or perhaps an item list of range of
blocks which would allow TRIM to be done on a file with many fragments
with one IO operation from $DELETE to the driver.