How to zero disk blocks?

[Bob Niepostyn]

Does anyone know of a better method then the described below.

I want to write zeros to disk free space.

One method is to create file and then erase it, as per the following pseudo-code:

$ Create ZERO.TMP /Allocate=n

$ Set File/End ZERO.TMP

$ Delete/Erase ZERO.TMP;

If the whole disk is to be zeroed then:

$ Initialize/Erase=Init disk:

The reason for doing it is that HDS storage system can run ZPR (Zero Page Reclaim) Utility thus reducing storage usage. This should work for thin provisioning.

[Hein van den Heuvel]

Close.... except there is no  $create/allocate

You can use $ COPY NL: ZERO.TMP/ALLO=1234

If you can use $ SET VOLUME/HIGH , then you don't even need the DELETE/ERASE because SET FILE/END will pre-write zeroes when HighWater marking is enabled.

Or create a relative file.

That will also be pre-zeroed (except block 1) with a single QIO (IO$_WRITEVBLK OR IO$M_ERASE)

$ create/fdl="fil; org rel; all 1234; buc 63; rec; siz 123" tmp.tmp

Cheers,

Hein

[Editted to make it more HWM and SET FILE/END more clear. Thanks John.]

[John Gillings]

Hi Bob,

  Long time!

  If you really want zeros, you'll need to be careful with DELETE/ERASE. It scrubs the blocks with the system security erase pattern, which is not necessarily zeros.

I believe if you have high water marking enabled, the SET FILE/END should fill blocks above the highwater mark file with zeros.

I'm not sure I understand why "ZPR" might help reduce storage usage, but if that's a good thing, perhaps you should ensure your system security erase pattern is zeros and set the volume to erase on delete? Deletes will be more costly, especially for large files, and users must understand that once they delete a file, it's really gone. No chance of scavenging it back.

[Bob Niepostyn]

Hein,

Thanks for your advice I have picked up a thing or two from it.

BTW: I am aware that there is no “create/allocate” and that is why I indicated that this is a pseudo-code.

Regards, Bob.

[Bob Niepostyn]

John,

Indeed - long time!

I would love know how to force "security erase pattern" to zero and I would appreciate some advise. At the moment it seems to work.

Setting volume ERASE_ON_DELETE and/or HIGHWATER_MARKING could dramatically affect performance at all times, while executing DELETE/ERASE only when it is performed. Hence I selected the later.

ZPR reduces storage when the disks (or LUNs in storage terminology) are thin provisioned. I this case we are getting charged only for what we actually use rather than for what is allocated to us. ZPR Utility runs on the storage server and hunts for storage blocks (42MB) and if finds a zeroed one id removes it from the set of blocks that make the LUN thus reducing used space. Hence the idea of zeroing unused disk space.

Regards, Bob.

[Hein van den Heuvel]

Bob,

I've played these games as well, because once a year I create a bootable OpenVMS image for our Sales Engineers with the latest (Attunity, RMS-Logger, ODBC,...) software installed and update temp licenses. After configuring I delete all .LOG and .TMP files, Purge everything and allocate all free blocks in a file to zero, before zipping up the result.

That saves 'tons' on the target zip and network.

>> Setting volume ERASE_ON_DELETE and/or HIGHWATER_MARKING could dramatically affect performance at all times, 

Just SET VOLU/HIGH right before the SET FILE/END, and remove afterward... it's dynamic.

No need to dismount / re-mount a disk to activate.

fwiw... In your situation I would consider a specialized program to 'sweep' the disk free-space bitmap, a settable chunk at a time. Take out a volume lock, find first X (10,000?)  freee cluster, QIO ERASE the corresponding LBN's (easy math), Release lock, wait  Y (10) seconds and tackle the next chunk, untill EOF in BITMAP.SYS.

This will NOT get  the free blocks in the per-cluster-member free block cache, but that's a good thing because it is expensive to flush those caches, and those blocks in the cache will be the first to be (re) used anyway!

Cheers,

Hein.