ADSM-L

Re: tape mount retention behaviour

2001-02-06 17:11:31
Subject: Re: tape mount retention behaviour
From: Joe Faracchio <brother AT SOCRATES.BERKELEY DOT EDU>
Date: Tue, 6 Feb 2001 14:13:13 -0800
Steffan , Joek,
        no, not really.
 As I stated originally, previously in 3.1.2.20  I observed the tapes
being dismounted as soon as another request of any kind was pending
regardless of their retention period.  And I've observed tapes staying
mounted for the full retention period when there's no need for the drive
by a pending mount request.

Now with 3.7.2 I'm not seeing this 'nice' behaviour but the now the tape
sits there blockin another request until the full mount retention expires.
This is inefficient in a 2 drive system.

And I'm not pointing to restore request only I'm pointing out this
behaviour for all mounts.

Setting it to  1 or zero is not the answer. THere are times when I want a
tape to stay mounted until the drive is needed for something else, two I
can think of are THE offsite/COPYPOOL tape because I run backup diskpool
copypool every so often and , more importantly, when a user is running
successive restores and keeps requesting the same tape.

Has there been previous discussion of this?  I can't find it on adsm.org.

.. joe.f.



Joseph A Faracchio,  Systems Programmer, UC Berkeley


On Mon, 5 Feb 2001, arhoads wrote:

> It does work that way.  If a client is backing up to tape, directly or
> not, keeping the mount avoids thrashing.
>
> Steffan
>
> Joel Fuhrman wrote:
> >
> > I thought it always worked this way.  At one time I was going to put in a
> > request to have two mount retention times.  One for when there are no
> > pending request for a drive and the other for when there are pending
> > request.
> >
> > On Mon, 5 Feb 2001, Joe Faracchio wrote:
> >
> > > I recently upgraded from 3.1.2.20 to 3.7.2.0
> > > and notice a very annoying behaviour.
> > >
> > > The system keeps an idle tape mounted for the full retention period
> > > specified despite the pending mounts that are waiting.
> > >
> > > when / where will this be fixed???
> > >
> > > thanks ... joe.f.
> > >
> > > Joseph A Faracchio,  Systems Programmer, UC Berkeley
> > >
>