Roger,

Why not have an additional "next" stgpool beyond your 10g tape pool with
maybe one or two volumes allowed, and maxsize nolim?  If a volume appears
in the storage pool, then a "q  content count=10" will usually be
sufficient to pinpoint your more egregious nodes - you won't get many
files of this size onto a single volume.

If your objective is to prevent *any* tape mounts during backup, then
assuming that you have sufficient random access disk storage pool, set its
maxsize to nolim, and put any size filters on the subsequent pools in the
heirarchy.  Migration will then take care of the size filtering, and will
use the "actual stored size" of the file, rather than the "size-on-client"
- which is what happens during backup. [Thanks to R. Sims for that one]

Regards

Dave
WindowsError 016: Recoverable error. System destroyed anyway.
____________________________________________________
Dave Frost
Technical Consultant
SunGard Availability Services (UK) Limited
London Technology Centre
Heathrow Corporate Park
Hounslow
UK.  TW4 6ER
Tel:           +44 (0) 800 2799 166
Fax:          +(0) 20 8080 8112
mailto:dave.frost AT sungard DOT com
____________________________________________________
Keeping People and Information Connected (TM)
http://www.availability.sungard.com





Roger Deschner <rogerd AT UIC DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/06/2006 16:50
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
[ADSM-L] Files stuck in disk stgpool






I'm looking for a strategy to attack a strange problem of stuck files
and failing migration.

In one heirarchy, I have a file size limit of 10g for the disk storage
pool, and also a limit of 10g for the tape pool it migrates to. The idea
is to prevent a client backup session from ever mounting a tape
directly, which is very inefficient.

We are using client compression.

There exists a client somewhere, who has a 9.99gb file that is of a type
that is already compressed (a jpeg photo, or a zip file, for instance).
The server compares its 9.99gb size to the 10gb limit, and says "OK,
back it up", and it comes down the wire into the disk storage pool.
However, when it arrives, it has grown by being recompressed, so that
now it is larger than 10gb.

Now it's stuck in the disk stgpool, and cannot be migrated to tape.
Migration processes repeatedly fail and are restarted. Things grind to a
halt.

This has now happened twice. My only fix is to temporarily raise the
tape pool's limit to get the stuck file migrated. However, this could
allow a client backup session to mount a tape.

Anybody got any better ideas?

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu