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

[Jan-Erik Soderholm]

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.