|
Re: [Networker] volretent in 7.4.x
2009-02-09 15:28:53
On 2/9/09 3:01 PM, dmitri wrote:
Francis Swasey wrote:
It is not a "no issue" ...
I know Frank, I know and agree wit hyou. I was just quoting EMC. I submitted a ticket with teh
request to change "mminfo" behaviour in terms of volretent,clretent and ssretent, but
it's like hitting a brick wall with a forehead. They are insisting that everything "works as
designed", here's their detailed explanation why your, my and others' problem is not a problem
at all and why we all should be happy:
This is NOT a bug. In 7.3 NW and beyond, the Individual Clone Retention Policy feature introduced the concept of "saveset-clone-instances" for a saveset, each residing on a seperate volume. a) Each saveset-clone-instance(unique "cloneid") has its own "retention
period"(configurable) - and that is represented via "clretent" field in "mminfo". b) So, "ssretent" is the "saveset retention period" - and that is the MAX of the "clretent" value among all the "saveset-clone-instances". You
need to check what the "clretent" values are for each of the saveset-clone-instances(have same "ssid" but different "cloneid") - the "ssretent" for ALL the instances will be the SAME and it will be the MAX value of the "clretent".
Logically, a "saveset" does not "expire" until ALL its instances "expire". So, there will be one "recoverable" saveset-clone-instance until the period noted in "ssretent" is passed. The "clflags" will reflect the state of the
"saveset clone instance"(browsable, expired
!
) and the "ssflags" will report the status of the "saveset" in general - the "ssflags" will show "E" only when ALL of the clone instances(note, each instance is on a different volume) of that saveset have "expired" and the "clflags"
of ALL show "E". Hope this explanation is clear enough. The "mminfo" query to run, to compare "ssid", "cloneid", "ssretent" and "clretent" would be something like: mminfo -q "name=" -r "ssid, cloneid, ssretent,
clretent, ssflags, clflags, volume" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ c) WRT "volretent"(volume retention period), the logic is: A volume "expires" when ALL the saveset-clone-instances on it "expire"
======================================================================== So, when the "saveset-clone-instances" pass the individual "retention period"(noted by "clretent"), they "expire". And, when ALL of them existing on the volume pass their Individual
Clone Retention period, the volume is marked as "ex
p!
ired"(eligible for recycling). d) That means that "volume retention pe
riod" is the MAX of ALL the "clretent" values of ALL the saveset-clone-instances on that volume. So, you need to check all the "saveset-clone-instances" on that volume for the "clretent" values, and the "volretent" will be the MAX of the
"clretent". noted. You could run "mminfo" to check this: mminfo -q "volume=" -r "ssid, cloneid, ssflags, clflags, ssretent, clretent" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The volume will not "expire" until ALL
the saveset-clone-instances on it "expire" - thats is, they pass their "clretent" and "clflags" show "E"). That is, "volretent" is based on "clretent" values of the saveset-clone-instances on that volume. NOTE: the "ssflags" may
or may not show "E" - and "ssretent" may or may not be greater than the "volretent". As "ssflags" and "ssretent" take into consideration ALL the saveset-clone-instances for a saveset(each clone of a saveset resides in a seperate volume) before
marking the saveset as "expire
d!
" or "eligible for recycling". Hope the above explanation is clear. The 7.3
and above Manpages and Admin Guide can be referred for additional info.
If the 7.4.4.build.634 code worked by that description, I'd be less
upset. The problem with the 7.4.4.build.634 (ga released code) is that
it sets the volretent value to the maximum ssretent value and not (as
they are describing) to the maximum clretent value. Therefore, the
volretent values are wrong.
Even with the fix installed, I'm being told that there is *no way* to
correct the existing volretent values that are in error. Seems like BS
to me. (Their program broke the value, it shouldn't be very hard to
write some code to go fix it).
Anyway. I'll know tomorrow morning whether their fix even keeps the
volretent value from being incorrectly modified.
The real shame here is that this worked correctly in 7.3.x (where x was
2 and 3 -- I never ran 7.3.4) and is broken in 7.4.3 ad 7.4.4... what
kind of regression testing are they running anyway... I have to believe
that it wasn't very good whatever it was.
I recently heard tell that 7.5 is the FIRST version that had the entire
code base run through one of those super glorious checkers to find
security and logic bugs. Yet, we see here on this list of people still
having issues with 7.5.
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
|
|
