I talked to the Support Center yesterday. They didn't know if this
was normal, but they said since I had a good DB backup, to go ahead
and let the expiration run to completion. I did a "Q OCC" before
and after (and could compare the results as expiration ran). It does
still appear to process in node/filespace order, and I believe Thomas
is right that the number of objects examined are just those which are
eligible for deletion. Maybe the ones that are examined and not
deleted are files for which ADSM only has one copy.
Thanks to those who responded. I guess our v3 upgrade was a
success (and with one day to spare!). It's too bad that the Support
center can't give better answers on this sort of thing...
--
Gene Mangum
Gene Mangum
University of Michigan Medical Center
On Tue, 30 Jun 1998, Thomas A. La Porte wrote:
> We noticed that behavior when we moved to v3 as well--and had the
> same reaction! I believe the difference in v3 from v2 is that the
> server is precomputing likely candidates for expiration, and then
> examining those and only reporting statistics for the files
> examined, not those excluded by the pre-processing.
>
> At least that was our guess as to what was going on.
>
> -- Tom
>
> On Tue, 30 Jun 1998, Gene Mangum wrote:
>
> >I just upgraded my server to 3.1.1.3 yesterday. Every night, I have a
> >set of scripts which process the days backups as follows:
> >
> > - force migration of disk stg pools to tape
> > - backup stg pools
> > - backup DB (2 copies - 1 offsite, 1 onsite)
> > - expire inventory
> >
> >Since last night was the first run under v3, I watched closely. It went
> >OK for the most part, but when expiration started, it seemed to be
> >expiring too much, so I cancelled it and locked all nodes (in case I have
> >to back out). When I cancelled it, the numbers were: examined-6465,
> >deleted-6389. This seems like ALOT!
> >
> >Can anyone explain what might be happening? Thanks for any help.
> >
> >--
> >Gene Mangum
> >University of Michigan Medical Center
> >
>
|
