Hi Eric,

I know this behavior and am trying both to warn John (the initial poster)
and to clarify what Alan wrote.
As far as I know (and have seen many times) a file goes direct to tape if
it is greater than "Maximum Size Threshold" of the storage pool. Next file
smaller than the threshold goes again to disk (as expected). After the pool
becomes 100% full the clients stop waiting migration to finish NOT just to
free enough space for the file. And if the next pool is collocated the
migration of small files can take too long (as discussed recently).
As a conclusion - lowering LOWMIG can help but the value have to be chosen
thoughtfully. Otherwise the result might be worse.

Zlatko Krastev
IT Consultant





"Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM> on 29.10.2001 15:45:09
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: Spill processing please help - lowering LOWMIG

Hi Zlatko!
This is 'normal behavior'. When backups go to a 100% full diskpool TSM
tries
to allocate storage in the nextstgpool defined for your diskpool, which is
probably your primary tapepool. So all backups are going to wait for
mountpoint in the tapepool. That's why the client backups seem to 'hang'.
Although migration kicks in and frees the diskpool, these clients will
never
switch back to the diskpool.
You should always try to prevent a 100% full diskpool. I agree that this is
not always possible, unless you have a very large one. I have run into this
situation numerous times, which can result in very nasty problems (Oracle
databases stop working, because the archive logfiles are not backed up).
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines