I believe that aggregation explains the difference in Physical Space
Occupied numbers. I believe the differences in Logical Space Occupied
are due to rounding of numbers. I'm confortable when the number of
files are the same and the Logical sizes are close.
David
>>> bbullock AT MICRON DOT COM 01/11/06 6:23 PM >>>
I'll take a stab at this, but feel free to correct me if I'm
off-base:
I believe what you are seeing there is the effects of the
aggregation that TSM uses as it "group" files together when writing to
sequential media. As the aggregation of files on the primary tapes and
on the copypool tapes don't necessarily match each other,(because of
timing of your migrations, when the "backup stgpool" commands are run,
they are written out in a different order and are aggregated in
different groupings).
As various files expire from these aggregates it leaves "holes"
in them and then you will see a size discrepancy in both the physical
and logical sizes reported between the primary and copypool reported
sizes.
Ultimately, I look at the file count as a good indication if I
have everything copied that should be, as sometimes the size
differences
can be rather large, especially where a host has been around forever
in
a storagepool with other hosts that have a high turnover rate, like
this
host's filesystem:
Node Name Type Filespace FSID Storage Number of
Physical Logical
Name Pool Name Files
Space Space
Occupied Occupied
(MB) (MB)
---------- ---- ---------- ----- ---------- ---------
--------- ---------
AMX72X Bkup /usr 2 COPYPOOL 58,291
3,086.62 2,506.24
AMX72X Bkup /usr 2 I_TAPEPOOL 58,291
2,611.55 2,506.18
That's my explanation. If that's not correct, I hope there's
another answer and I don't actually have big problems in my
environment
and am not getting everything copied off-site like I think I am. (gee,
I
hope not....)
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of
Larry Peifer
Sent: Wednesday, January 11, 2006 3:46 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Best way to compare the pools ?
This thread got me to checking more closely and I discovered the
following situation. We daily use 'backup stgpool tapepool4 tapepool5
maxprocess=2'
to our off-site library which happens to be identical to our on-site
library. During the query below I noticed discrepancies for the
old-c$
filespace. The # of files is the same, but the Physical and Logical
space differs between the two tapepools. This is different then 99%
of
the other filespaces in the report and I'm wondering if it is
indicative
of a problem.
I'd thought about doing an Audit Volume but don't know how to find out
what tape volumes the particular node/filespace is on. Ideas?
So I took another track and just renamed the c$ filespace to old-c$
and
let the nightly backup make a new c$. The results of that are
indicated
below. All numbers for the new c$ match up as expected.
What other things can be done to manage or fix issues like this? In
most of the cases from my full report all 3 numbers agree. A few have
a
difference in the Physical space number. A few others show a
difference
in the Logical number. And a very small case show a difference in all
three numbers.
tsm: TSM>q occ socats
Node Name Type Filespace FSID Storage Number
of
Physical Logical
Name Pool Name
Files
Space Space
Occupied
Occupied
(MB)
(MB)
SOCATS Bkup SYSTEM 1 TAPEPOOL4
140,409
19,254.82 19,254.82
OBJECT
SOCATS Bkup SYSTEM 1 TAPEPOOL5
140,409
19,254.82 19,254.82
OBJECT
SOCATS Bkup \\socats\- 2 TAPEPOOL4
138,460
9,759.44 9,538.10
old-c$
SOCATS Bkup \\socats\- 2 TAPEPOOL5
138,460
9,674.01 9,538.09
old-c$
SOCATS Bkup \\socats\- 3 TAPEPOOL4
81,268
4,644.62 4,644.62
c$
SOCATS Bkup \\socats\- 3 TAPEPOOL5
81,268
4,644.62 4,644.62
Richard Sims <rbs AT BU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/10/2006 11:07 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Re: [ADSM-L] Best way to compare the pools ?
On Jan 10, 2006, at 1:29 PM, Vats.Ashok wrote:
> We have primary pool and offsite pool. We run backup from primary to
> offsite pool everyday using cron. I was wondering what is the best
> practice to copy primary to offsite pool ? Also how do I compare the
> two pools to see if offsite is caught up with primary.
> Typically I use q * * stg=primarypool & q * * stg=offsitepool but it
> takes a long time to run these commands & compare the output.
If the primary pool is backed up only to that offsite copy storage
pool
(and not also an on-site copy storage pool), you can do 'select
* from auditocc', which is nearly instantaneous.
Richard Sims http://people.bu.edu/rbs
|