ADSM-L

Re: Why does ADSM backup directly to a tapepool

1999-11-16 03:50:08
Subject: Re: Why does ADSM backup directly to a tapepool
From: Russell Street <russells AT AUCKLAND.AC DOT NZ>
Date: Tue, 16 Nov 1999 21:50:08 +1300
> > does anybody know in which casses ADSM decides to backup a small
> > file directly to a tapepool.

I have seen this when the disk based storage pool is almost full.  The
sequence of events is something like this:

 (a) The ADSM client tries to store a file
 (b) The ADSM server decides there is not enough room in the pool and
     the file needs to be stored in the next [tape based] storage pool
 (c) The ADSM server then mounts a suitable tape, stores one file
 (d) The ADSM server is also migrating files from disk to tape freeing
     disk storage
 (e) So that when that one file is stored there is now sufficent room
     in the pool for the next file.
 (f) The server switches from storing on tape back to storing on disk.


You might have your HIGH migration thresholds set too high.  The
default is 90%, so you only have a 10% buffer.

If your clients can pour data onto the ADSM server faster than it can
migrate it to tape, then the pool can be full for an instant and the
above happens.

I find that setting HIGH=70% LOW=50% works quite well for migrating to
DLT tape.


<mode=RANT>
DLT tapes have a long mount time and an even longer dismount time.

It is possible to get a [my ;)] server into a pathological state where
tens of clients are waiting for a tape mount to store one file each.
But they are not going to get a mount point because the migration
processes have all the tape drives in use AND the storage pool is
still above the low threshold AND more data is arriving to keep it
above the threshold.  Not a pretty sight.

The workaround to that was to set the maximum migration processes to
one LESS than the number of mount points.  That guarantees there to be
one spare mount point for clients.
</mode>


Russell
<Prev in Thread] Current Thread [Next in Thread>