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:[EMAIL PROTECTED] ____________________________________________________ Keeping People and Information Connected (TM) http://www.availability.sungard.com Roger Deschner <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 05/06/2006 16:50 Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To ADSM-L@VM.MARIST.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 [EMAIL PROTECTED]
