WRITEMAP.SYS
Rob Young
I have an idea that might be obvious.
Since host-based mini-merge is coming to a future version of
VMS, I thought why not combine the tracking of "writes in progress"
on to a WRITEMAP.SYS?
The purpose would be twofold:
1) Allowing a BACKUP/MODIFIED_BLOCKS backing up only blocks
that have been written to since last full IMAGE.
(Let's face it, many of us are backing up databases
every night and in some/many of these databases little
changes night to night).
2) Memory required to track "writes in progress" could
be reduced and fixed in size.
The layout of WRITEMAP.SYS would be an index file each data node
would track 127 blocks at a time. Each 127 block to be tracked
would be a 9 byte entry.
Byte1 Byte2 Byte3 Byte4 Byte5 Byte6 Byte7 Byte8 Byte9
| Seconds of last write | Number of writes | Misc |
Bytes 1-4 would keep the time of the last write in seconds, offset
from an arbitrary base date - Jan 1, 2000 (future versions of
VMS would pick a higher base date if getting close to date overflow
68 years from now). Byte5-8 would track how many writes took place
between mounts. Clear this field on DISMOUNT (what kind of overhead?
What if it isn't cleared because of crash? Some background to
clear if inconsistent or mounting after crash:
SET VOLUME/CLEAR=WRITEMAPCOUNTERS).
Byte9 would be bits to play with. Zero bit 1 when full IMAGE
backups occur. flip Byte9 bit 1 on every write - no test and set.
By tracking number of writes, you could find out very hot regions
and perhaps dump those blocks (or more techniques) to identify
what is going on with a program/data region.
The number of blocks used by WRITEMAP.SYS wouuld be less than
4000 blocks for a 9 GByte drive (9 bytes * 145134 entries + 1200 block
index overhead - more overhead? less overhead?)
A home block would look like:
Byte1 Byte2 Byte3 Byte4 Byte5 Byte6 Byte7 Byte8 Byte9
| % | Reserved |
Byte1 would track total percent that have been modifed by looking
at bit1 of Byte9. That way you could write a DCL test wrapper:
$ percent_modifed = f$getdvi("''Target'","PERCENT_MODIFED")!since image
$ if percent_modifed .gt. 50
$ then
$ backup_quals = backup_quals + "/IMAGE"
$ else
$ backup_quals = backup_quals + "/MODIFED_BLOCKS/SINCE=IMAGE"
$ endif
The reason here is it makes little sense to do a modified backup
if 90% of your disk has changed. Might as well do a full image
and have that to fall back to. Conversely, it makes little
sense to do a full image if 5% of the disk has changed. When
doing 50, 100 GByte disks this can be a huge time savings - the
whole point.
Now the idea is whoever is mastering the "writes in progress"
for the host-based minimerge feature would flip the associated
bits for the 127 block region.
By tracking seconds since last write, you could alternately
backup modified blocks to the prior image and build up
associated DCL to support that infrastructure. Backup might
look like:
$ BACKUP/MODIFIED_BLOCKS/SINC="15-JUN-2003:03:00"
This would give the manager the comfort of knowing you could
restore 1 or 2 images and still apply the differentials to get
back a sane volume.
Likewise, the mini-copy could keep the memory used small by
tracking when the shadow was broken out and added back and simply
trundle down through looking at seconds since last write OR better
yet, flip bit2 on byte9 when shadow members are broken out on
every write, then shadow mini-copy would simply look at bit 2.
If bit 2 is flipped, copy that region back.
Rob
Rob Young
>
>
> 2) Memory required to track "writes in progress" could
> be reduced and fixed in size.
>
Make that:
Memory required to track blocks modifed for mini-copy
could be reduced and fixed in size.
Rob