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

[Jan-Erik Soderholm]

johnwallace4 at yahoo.co.uk skrev den 2015-06-20 13:30:
> On Saturday, 20 June 2015 09:28:08 UTC+1, Dirk Munk  wrote:
>> I suppose most of you will know what the TRIM facility is, but just to
>> make sure I will explain it.
>>
>> With flash memory you can do two things, you can write empty cells, or
>> you can erase written cells. You can not rewrite cells, like you would
>> rewrite written block on a disk.
>>
>> When you delete a file on a disk, not very much will happen. A directory
>> entry will be deleted, and somewhere the blocks of the file will be
>> marked as free. The actual contents of the blocks will remain unchanged,
>> that's why you sometimes can undelete them. When a new file needs those
>> blocks, they will be simply rewritten.
>>
>> If you would try to do the same thing with flash, you would get a
>> problem. Before the cells can be written again, they would need to be
>> erased. So it is an erase followed by a write procedure, and that is a
>> rather lengthy process. Your fast flash memory would suddenly become
>> rather slow. That is what happened in the early days of flash.
>>
>> You should also keep in mind that there is no direct correlation between
>> disk block numbers and the actual cells that are being used. The reason
>> is very simple, some blocks/cells would be rewritten (=erased + written)
>> very frequently, so they would reach their maximum number of erase/write
>> cycles very soon. The SSD has its own housekeeping to link disk blocks
>> numbers to cells.
>>
>> The solution the industry came up with is called TRIM. Now when you
>> delete a file, the SSD will get a list of blocks/cells it can erase, so
>> on the background all the cells of the deleted files will be erased, and
>> when a new file needs them they can be written immediately. If a block
>> in a database needs to be rewritten, the SSD will use erased cells to
>> write the new data, and will erase the cells previously used.
>>
>> As far as I'm aware VMS doesn't have TRIM yet, not even the Itanium
>> version. So that would make SSD's not very suitable for VMS.
>>
>> It becomes even more difficult when you're using an emulator, and your
>> VMS disks are in fact container files on a disk of the host operating
>> system. A delete operation of the guest operating system is not seen as
>> a delete operation by the host operating system, so even if the host
>> supports the TRIM facility, it can not use it if the guest issues a file
>> delete. This applies to all operating systems of course, not just to VMS.
>>
>> In my view the only way to use SSD's with VMS is never to allocate the
>> full size of the SSD for a VMS disk. Suppose you have a 256GB SSD, then
>> you would for instance allocate a 200GB disk on that SSD. That way there
>> is always 56GB of erased space available. As soon as the SSD needs to
>> rewrite a disk block, it can use cells from the 56GB of erased space,
>> write the new data, and erase the cells that were formerly in use. This
>> also works with emulated disks (container files) on the disk of the host
>> operating system. The disk of the host operating system should never
>> allocate the full size of the SSD, that way there is always enough
>> erased cell capacity on the SSD.
>
> At least one vendor whose name I forget and can't quickly
> identify (but should be recognisable round here) builds (built?)
> disk controllers which behave the way VMS expects but which hide
> administrivia like revectoring (renumbering?) and wear levelling,
> so the flash device gets used the way it likes, and VMS gets to
> behave the way VMS people like.
>
> Native support for SSD would be good in due course [1].
>
> But isn't the enterprise-class fashion this week to put everything
> in main memory, SAP HANA style?

I must confess that I don't realy understand this "memory database"
and "HANA" fuzz. Looking right now (355 days of database beeing "open")
we have a little more then 99.7% memory hits when looking for some
database page in our Rdb database. The rest 0.3% are read from disk
and these 0.3% are mainly from the nighly batch runs. During normal
work we more or less run "in memory". Besides of the usual log
file write and such, but that is the same for HANA anyway...

Jan-Erik.


>
> If only VMS had a RAMdisk driver, everyone's existing apps could
> operate at main-memory speed rather than disk-limited speed.
>
> Oh well, maybe one day, shortly after HP's "Machine" comes to market.
>
> Or maybe DECram (and unsuported precursors) still exist.
>
> Progress.
>
> [1] Who remembers the OpenVMS Technical Journal? Issue 19 (Feb 2013)
> had an article on "OpenVMS best practices for using SSD". Of course
> you can no longer find it on HP's website, in line with the company's
> policy of continuous product and service improvement.
>
> For the moment, you can still find an alleged link to the article at
> http://h71000.www7.hp.com/openvms/journal/v19/index.html
>
>
> Oh look, using a proper search engine rather than the HP website finds
> the said article (at the moment):
> http://h20565.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c04618690
> where the following text appears:
> "HP solid state drives (SSDs) deliver exceptional performance for
> customers with applications requiring high random read IOPS
> performance."
> and
> "OpenVMS supports SSDs starting from OpenVMS V8.4 Update 700. SSD
> drives  in OpenVMS are supported in both HBA and RAID mode with a
> SAS controller. HBA mode provides direct access to SSD devices as a
> pass-through module, and with RAID we can take advantage of SAS
> Controller to carve RAID disks, of multiple SSD devices."
>
> The word TRIM does not appear in that document, but there are
> a number of other handy snippets unrelated to performance, e.g.
>
> "An SSD's lifetime depends on number of writes performed to it. We
> can find out the remaining lifetime of an SSD using the lexical
> F$GETDVI with item code SSD_USAGE_REMAINING (based on current
> workload in percentage) and  SSD_LIFE_REMAINING (estimated number
> of days left as per current workload). SSD has to be connected
> locally for this lexical to work."
>