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

[Dirk Munk]

David Froble wrote:
> Dirk Munk wrote:
>> I suppose most of you will know what the TRIM facility is, but just to
>> make sure I will explain it.
>
> <snip>
>
> Ok, there are at least 2 scenarios.  Direct attach and SAN.  For SAN,
> such problems should be handled entirely within the SAN.  For direct
> attach, there is the question of what might be appropriate for each
> device.  Some implementations might be bad for some devices.
>
> In some cases, I'm not sure this entire subject is the business of any
> OS.  I've got to believe that solutions would be rather tied to specific
> things implemented in the SSD hardware.
>
> That written, I'm led to believe that proactive is better than reactive.
>   If released blocks need to be cleared, then assigning them to some
> "work file" that exists for a background task to clear the blocks, and
> then release then to the "free list", whatever that is.  No locking
> issues, only the clearing task should have access.  There would be
> locking issues, perhaps, when moving cleared blocks to the free list.
> Adding to the end of any free list might also encourage the avoidance of
> re-using certain blocks more than others.

It seems to me as if there is some kind of misunderstanding.

Suppose at the moment disk block 1000 is occupying cell 20000 on the 
SSD. Now you rewrite block 1000, and what may happen then is that cell 
300000 is written and cell 20000 is erased. The SSD will know in which 
cell the contents of block 1000 can be found. The SSD will also take 
care that the number of erase & write cycles will be levelled as much as 
possible to prevent certain cells to be worn out prematurely.

There is no need for a background task on the OS to erase blocks, that 
is a function of the SSD. You only need to supply the SSD with a list of 
blocks that can be erased, and the SSD will take care of it. Locking 
issues can not exist, the SSD will always use erased cells to write.