I use 15GB DLT tapes for my tape pool, I was assuming that ADSM was
writing as much
data for a node on them as possible. I have always used collocation for
this pool.
The person that complained may be overstating the 'lots of mounts', so I
just wanted
to verify. He has a small machine, and I would suspect that it would
not put his
data all over.
I have been converting my old 8MM tape (no collocated pool) to the new
DLT library
with 'MOVE DATA 8MMXXX STG=BACKUPPOOL' assuming that the natural
migration process
would collocate his files into the new DLT collocated pool. Am I
thinking about this
wrong? Tape to tape processes are very slow, and this seems to be
painfully true
when you are dealing with nocollcated -> collocated.
I was just hoping there was some majic command that I could issue to
show me where
a nodes files were (on what volumes).
Since reclaims are broken, I have been manually moving my 'FULL' DLT's
back into
my disk BACKUPPOOL, and letting the migrations deal with the
collocations.
I have 65 tapes in the DLTPOOL now, so 5 mounts would not bother me, 10
might concern
me. I don't allow SCRATCH volumes.
Dwight E. Cook wrote:
>
> There are apars that address this. I'm slow and on ptf9 but have 10,
> 11, & 12 here but can't remember which one includes some enhancements
> to reduce the number of partially filled tapes with collocation being
> turned on.... Grab ptf-12 and scan for collocation... If the right
> combination of events occur older adsm servers would grab scratch
> tapes to write to ending in multiple partially filled tapes.
> NOTE : the number of tape mounts will basically boil down to how much
> data is on a client, how many copies you are keeping, and what data
> you want back...
> REMEMBER : without collocation, over time, you stand a good chance of
> haveing a file from a given node on each and every tape in your
> library sooooo many tape mounts is a relative term here... is it many
> when compared to mounting every tape in your library?
> later
> Dwight
>
|
