I wrote:
> 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
On Mon, Sep 27, 1999 at 01:41:02PM -0400, Jeffrey Hutzelman wrote:
> 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.
Perhaps this is just my paranoia, as we have had several years now
of dying fileservers or failing disks, and often I got replicated
volumes which could be straightened out only by deleting one or
more of the readonly copies, doing 'vos adds' again, and then 'vos
rel'.
I wrote:
> to release it), then checks the timestamps and sizes of all files
> in the volume (and some similar check for symbolic links, at least),
and Jeffrey answered:
> 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.
Aha! I didn't know there was a 'Last Update timestamp'; obviously this
is much more efficient.
> 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...
It sounds like something extremely useful.
-- Owen
[EMAIL PROTECTED]
