-----Roger Deschner <ADSM-L AT VM.MARIST DOT EDU> wrote: -----

>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?

If the names of the already compressed files follow well defined
conventions, and if you can get client configurations changed,
you can use 'exclude.compression' statements to prevent compression
of such files. We eliminated most of our repeated compression
problems by putting 'exclude.compression *.gz' lines in the
include/exclude files on our Oracle servers.