Storage pools of type DISK are random access, i.e. everything can randomly
be stored there. Over disk devices you can have a filesystem and files in
it to be treated as sequential volumes. You can think of them as virtual
tapes where the directory is the library and the files are tapes. Thus for
storage pool of type FILE normal reclamation policies and facts apply. Why
to reclaim the pool used for reclamation or access it sequentially?!
The MAXSIze parameter is for maximum file size to be stored in THIS storage
pool. Otherwise if the file is bigger it goes down the storage hierarchy,
i.e. goes direct to next storage pool which is normally tape pool.
If you set maxsize limit to the reclamation pool at least I cannot predict
but am expecting that reclamation for volumes containing files larger than
your limit will never happen. Better do not do it or test it extensively.

The question is what to be the size of the reclamation pool! Size of a
volume will work for sure but ... let's make some calculations:
Having reclamation threshold of XX % and (max) volume size of YY GB
Volume eligible for reclamation will contain at least XX% freed space or no
more than (100 - XX) % data.
So we will be able to move the data to a reclamation pool with size of only
(1 - XX/100) * YY GB !!
Or with real numbers - for example reclamation threshold of 80 % and
DLT8000 tapes with compression up to 3:1
The max size of a volume is 120 GB and at least 80% of it are free. Data
left on the tape will be no more than 24GB and reclamation pool of this
size will work.
The volume becomes empty and it data is written somewhere else (or even on
it but from the beginning and we are having transition <full to be
reclaimed> ==> <empty> ==> <filling> ).
BUT this is having a drawback - it will increase the number of mounts.
Going back to the real example:
Let's have five tapes (V01 - V05) to be reclaimed and single drive.
1. We will mount tape V01, read all data from it and write it back.
2. Mount tape V02, read it
3. Mount tape V01, write data from V02
4. Mount V03, read
5. Mount V01, write
6. Mount V04, read
7. Mount V01, write
8. Mount V05, read
9. Mount V01, write
Thus we got 3 more mounts of V01. If we have larger reclamation pool we
will have read of V01, V02, V03, V04, V05 and single write to let say V01.
And have another think in mind - in the example 5 times 20% data were 100%.
But for reclamation threshold 85% (15% data) we will have 6 2/3 volumes for
a new one to fill. The seventh volume will mount twice - first 10% data
going to first reclaimed volume and the rest (5%) to second volume. If we
round up those 6 2/3 to 7 times and assure reclamation pool at least 7x15 =
105% of max volume size we can avoid even this double mounting.

All this is just my theoretical thoughts but very soon I will have prove
them in real life (I forgot to mention in my last post about 7337 library
that it is with only one drive :-0  )
That's from me.


Zlatko Krastev
IT Consultant





"Joshua S. Bassi" <jbassi AT IHWY DOT COM> on 11.09.2001 22:58:38
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: reclaimation pool/volume question.

When you define the disk storage pool you need to create a device class
of FILE type.  In the definition there is a maxsize variable (I believe
from memory).


--
Joshua S. Bassi
Joshua S. Bassi
Independent IT Consultant
IBM Certified - AIX/HACMP, SAN, Shark
Tivoli Certified Consultant- ADSM/TSM
Cell (408)&(831) 332-4006
jbassi AT ihwy DOT com