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

[Jan-Erik Soderholm]

johnwallace4 at yahoo.co.uk skrev den 2015-06-20 13:18:
> On Saturday, 20 June 2015 10:28:45 UTC+1, Jan-Erik Soderholm  wrote:
>> Dirk Munk skrev den 2015-06-20 10:28:
>>> 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.
>>
>> What about large SAN's? When we moved our VMS disks over from the
>> old HSZ80/HSG80 storage to a large IBM DS8000 system, the sysman
>> there said that he first thought about putting "our" volumes on
>> flash-only storage "since they was so small anyway".
>>
>> Now, the SAN doesn't work with "container files", as far as I know.
>> Each VMS file is seen as a file by the SAN also. And I would guess
>> that any TRIM facility would be builtin into the SAN controllers...
>>
>> Or is the TRIM command something that *must* be sent from the OS
>> itself?
>>
>> Jan-Erik.
>
> SANs surely don't see "files", they see blocks?
>
> I'm struggling with the sentence "Each VMS file is seen as a
> file by the SAN also". In a UNIX or Windows setup, a NAS box
> might see a file as a file (using NFS or SAMBA or whatever).
> Not obvious how that applies in a block-oriented VMS+SAN setup.
>
> Also, TRIM deals in blocks.
>
> Have a think about that and see if you can rephrase your question?
>

Well, if I was *that* wrong, there is not much to rephrase... :-)

But yes, that might very well be correct, the IBM DS8000 system
never sees any VMS files or filesystem...

And besides, after doing some additional rading around TRIM, it
seems as the TRIM command has to be issued by the system knowing
enough about the filesystem.

Anyway, our storage was finaly put on some standard HDD pool...

Jan-Erik.