I'm pretty sure that VSTORE does no disk i/o whatsoever.

While it's always been a mystery what VSTORE actually does, I find it hard
to believe that it actually compares anything on the tape with anything on
disk, since I've never heard of a "files do not match" kind of error from
:VSTORE, and there are do requirements for performing the VSTORE before you
change anything on disk or while users are not accessing any of the files to
be "compared", etc.  Also users are never prevented from accessing files
because "VSTORE's got them" etc.

So it's possible that :VSTORE may do no more than read every block on the
tapes to make sure there are no read errors.

My guess though would be that it simulates doing an actual RESTORE to some
degree, stopping just short of actually allocating any disk space or
actually writing anything to disk.  This would allow it to catch problems
with the software compression code and other things which just reading the
tape blocks could miss.

As far as why the VSTORE is slower than the STORE, a guess would be that the
STORE process has gotten extremely optimized over the years, but that nobody
has ever bothered making RESTORE/VSTORE faster since when restoring you're
generally just happy to be getting the data at all and not to picky as to
how long it takes.

Other possibilities are that you're using an "asymmetrical" option on the
:STORE command such as one of the ONLINE modes or possibly compression which
for one reason or another is more complex at RESTORE time than it was at
STORE time (though I would expect compression to be slower than
decompression generally).

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *