ADSM-L

Re: mediawait

1999-08-20 10:58:14
Subject: Re: mediawait
From: bbullock <bbullock AT MICRON DOT COM>
Date: Fri, 20 Aug 1999 08:58:14 -0600
        I also think they are looking for the same tape. Do a 'q sess f=d'
and see what tape it is waiting for.
If it is the same tape then I'll bet that the tape storagepool is
collocated. The order that a collocated pool looks for tapes to write on is
this: (from Administrators Guide)

How the Server Selects Volumes with Collocation Enabled

When collocation at the client node level is enabled for a storage pool
(COLLOCATION=YES) and a client node backs up, archives, or migrates files to
the
storage pool, the server attempts to select a volume using the following
selection order:

1. A volume that already contains files from the same client node
2. An empty predefined volume
3. An empty scratch volume
4. A volume with the most available free space among volumes that already
contain
data

When collocation at the file space level is enabled for a storage pool
(COLLOCATION=FILESPACE) and a client node backs up, archives, or migrates
files
to the storage pool, the server attempts to select a volume using the
following selection
order:
1. A volume that already contains files from the same file space of that
client node
2. An empty predefined volume
3. An empty scratch volume
4. A volume containing data from the same client node
5. A volume with the most available free space among volumes that already
contain
data



        Since it sees this client already has data on a 'filling' tape, it
will wait for that tape to become free to use it (choice #1 in the first
list). The easy way to get around this would be to turn collocation off. If
that is not an option, you can get around this by "seeding" another tape
with data from that node. Just do a 'move data' on that tape and cancel it
once it has moved a couple of files. Next time the 2 backups run, there will
be 2 tapes from that node to put the data on. In my experience, this
'seeding' only has to be done once, because at the end of those 2 tapes, it
will append to a new scratch tape and 'seed' itself.

Ben



> -----Original Message-----
> From: Simon Watson [mailto:simon.s.watson AT SHELL.COM DOT BN]
> Sent: Friday, August 20, 1999 1:33 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: mediawait
>
>
> I expect they are waiting on the same tape.  The client name is the
> same so this is quite possible.
>
> Have a look at q sess f=d to see if it is waiting for a mount point or
> a specific tape.
>
> Regards,
> Simon
> ----------
> | From: rwagner /  mime, , , rwagner AT ZEUNASTAERKER DOT DE
> | To: ADSM-L /  mime, , , ADSM-L AT VM.MARIST DOT EDU
> | Subject: mediawait
> | Date: Friday, 20 August, 1999 9:26PM
> |
> | Folks,
> |
> | we have a 3494 with 4 3590 drives. Any ideas why i see media wait
> | of 13.5 minutes while three drives are free??
> |
> |
> | adsm> q se
> |
> |   Sess Comm.  Sess     Wait   Bytes   Bytes Sess  Platform
> Client Name
> | Number Method State    Time    Sent   Recvd Type
> | ------ ------ ------ ------ ------- ------- ----- --------
> --------------------
> |  4,274 Tcp/Ip RecvW   14 S    9.0 K 395.6 M Node  WinNT    ZSITSNT1
> |  4,277 Tcp/Ip RecvW    6 S    9.1 K 394.6 M Node  WinNT    ZSITSNT1
> |  5,228 Tcp/Ip MediaW 13.5 M   4.3 K     694 Node  WinNT    SAP_CL_DB
> |  5,229 Tcp/Ip RecvW    0 S   16.7 K   5.2 G Node  WinNT    SAP_CL_DB
> |  5,232 Tcp/Ip Run      0 S    5.8 K     271 Admin WinNT    WAGNER
> |  5,233 Tcp/Ip IdleW    0 S    4.4 M 107.7 M Node  WinNT    ZSASAPP1
> |
> | adsm> q mo
> | ANR8330I 3590 volume A00075 is mounted R/W in drive DRIVE1
> (/dev/rmt0), status:
> | IN USE.
> | ANR8334I         1 volumes found.
> |
> | adsm>
> |
> | TIA
> |
> | Reinhold Wagner, Zeuna Staerker GmbH & Co. KG
> |
>
<Prev in Thread] Current Thread [Next in Thread>