I have seen this before as well (though not the numerous sessions continuing
onto a new tape - have never waited around long enough ...).
As I have learned - server // (parallelism) overides drive //.
So if you dont have enough drives and available tapes (in the correct pool
etc etc) you might end up getting loads more streams onto one drive. I
normally fix this straight away.
I have as well seen that where it was writing 8 streams to a tape - and the
second one became available - it started the new savesets on the newly
available tape and eventuallyl balanced out at the configured 4 per drive.
Regards,
Riaan
-----Original Message-----
From: Robert Maiello [mailto:robert.maiello AT THOMSON DOT COM]
Sent: Thursday, May 20, 2004 3:04 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] 7.1: target sessions ignored when relabelling
recyclable tapes
Wow, I have not seen this (but now I'm going to check if my server is doing
it). Did you try playing with the load and mount sleep times of the
jukebox?
I do agree this behavior is a serious bug..did either of you log a case?
Were they able to reproduce it?
Robert Maiello
Thomson Healthcare
On Wed, 19 May 2004 19:34:11 +0100, Davina Treiber <Treiber AT HOTPOP DOT COM>
wrote:
>Ty Young wrote:
>> NetWorker 7.1, Solaris 8 (this is a server, or more properly, storage
>> node issue)
>>
>> Scenario: backups underway, and server is waiting for some quantity of
>> recyclable tapes (let's say 8.) Upon loading recyclable tapes, nsrd
>> makes some nsrjb requests to re-label 8 tapes. As soon as the first one
>> is labelled, however, it appears that not only is it loaded into a drive
>> for writing, but that a majority, if not all, of the suspended sessions
>> get routed to this one tape (i.e., target sessions for whatever drive
>> appears to be ignored.) The result is that we may see as many as 25-30
>> streams going to one tape, while the remaining 7 newly-relabelled tapes
>> sit idle in their drives.
>>
>> Anybody else seen this behavior?
>
>Yes, under several circumstances. A flaw in the code somewhere. It is
>very annoying because sometimes this can cause a backup to run for many
>times as long as it should, sometimes into the next backup window. It
>doesn't even sort it out when the tape fills, it still continues with a
>zillion sessions on the next new tape. Fix it Legato!
>
>--
>Note: To sign off this list, send a "signoff networker" command via email
>to listserv AT listmail.temple DOT edu or visit the list's Web site at
>http://listmail.temple.edu/archives/networker.html where you can
>also view and post messages to the list.
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.687 / Virus Database: 448 - Release Date: 5/16/04
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.687 / Virus Database: 448 - Release Date: 5/16/04
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
