West,
We have a major application that is using the API to archive/retrieve data
directly to/from tape (no disk storage pools, which are too slow), and it has
been subjected to the same kind of problems that you describe (except that we
have a few more tape drives than you do). Sadly, the only way we have overcome
this is by having the applications making its own tape drive management:
* Every so often, it checks how many tape drives are available, via a dsmadmc
command.
* It then keep a track of how many write and read requests it has originated,
and delays further reads (retrieves in our case, restore in yours) until the
current writes have finished - and reciprocally.
* This of course does not work very well as soon as reclaims, adsm backups, or
any tape drive related processes are started. But this is ADSM for you.
This kind of preemption is rather frustrating, as it often occurs when
applications have already written large chunk of files (in our cases, several
hundred of megabytes)
Note that, as far as I know, this is a "feature" of ADSM, which is not only
limited to the APIs, but also plagues the more conventional clients.
One possible course of action is to put a large disk pool in front of your tape
drives, and have low values of high treshold. This way, the data that you write
could go first to disk without being pre-empted by a tape read, and be migrated
when as soon as a tape drive is available.
--
Regards
Regards
+-------------------+----------------------------------+---------------------+
| Francis Dequenne | Systems Section | /~~\ /~~\ |
| ECMWF | e-mail: fdequenne AT ecmwf DOT int | / \/
\ |
| Shinfield Park | Tel: (+44 1734) 499361 | ECMWF |
| Reading | Fax: (+44 1734) 869450 | ECMWF |
| Berkshire RG2 9AX | Telex: (+44 1734) 847908 | \ /\ / |
| United Kingdom | | \__/ \__/ |
+-------------------+----------------------------------+---------------------+
|
