ADSM-L

Re: Expiration adsm 3.1.2.x

1999-04-02 05:10:39
Subject: Re: Expiration adsm 3.1.2.x
From: Paul Fielding <paul.fielding AT HOME DOT COM>
Date: Fri, 2 Apr 1999 03:10:39 -0700
Two questions regarding this issue:

1.   My understanding of the versioning problem (IX85298) is that once the
fix has been applied, each affected file will be corrected when it next gets
backed up to the server.  This was apparent as we did an expiry immediately
after applying ptf 16, but didn't get much joy.  The next day, however,
following a night of backups we expired literally terrabytes of data.

What I am wondering is this:  What happens to files that have too many
versions on the server but do not back up after the fix has been applied.
For example, say you have a copy group set to keep 5 extra versions, but due
to the expiry bug you end up with 20 versions of the file.  2 days before
you apply the fix, work on this file stops, and it no longer changes.  The
fix is applied, but because the file doesn't change, it doesn't get backed
up again.  Are we going to keep 20 versions of this file until someone
decides to touch it and cause a backup?


2.   This one can probably warrant a vague answer at best.  The server in
question currently has roughly 60,000,000 files stored on it.  Prior to
fixing(?) the expiry problem an Expire Inventory would examine anywhere from
1,800,000 to 2,500,000 files.  Ever since we've been running at 3.1.2.16
we've only been examining 700,000 to 1,200,000 files (All very rough
numbers).  Our total occupancy doesn't seem to be rising any more, but for
lack of knowing how the versioning algorithm works, I would have thought
those numbers are kinda low....(?)

So, with 60 million objects, what kind of numbers should I be expecting to
see examined?  I know I know, your mileage may vary drastically, but what
are other people seeing?

Later,
Paul


<Prev in Thread] Current Thread [Next in Thread>