> I can imagine running a job which looks at a RW volume and its
> RO copy, checks to see that it is not locked and that the RW
> copy is accessible (if either of these fails, it shouldn't try
I agree in principle, but these tests are probably not actually needed.
'vos release' already does the first, and the second will become apparent
immediately upon a release. The result would be that some manual cleanup
is required, but that is probably already the case if a RW volume is
inaccessible. Of course, YMMV.
> to release it), then checks the timestamps and sizes of all files
> in the volume (and some similar check for symbolic links, at least),
Eewwww. That's completely unnecessary. It is sufficient to compare the
Last Update timestamps reported by 'vos examine' on the RW and RO volumes;
if the RW volume is newer, it should be released. We have a perl script
which does this every night for nearly every replicated volume in our cell.
Last night it took about 1 hour to run, in a cell with 8439 VLDB entries,
209 of which are replicated, and 36 of which required releases. Of that
time,
6 minutes were spent scanning the VLDB, 14 deciding which volumes to
release, and the remainder actually doing the releases, one at a time.
I'll be happy to share this program, if others are interested...
