On Fri, Nov 24, 2006 at 12:30:27AM -0500, George Sinclair wrote:
> Now, I finally set the other tape (was read-only) to appendable. Within
> 30 seconds, NetWorker then stops requesting a writable tape
> (issues event cleared message) and then starts to load the other tape.
> However, before it loads it it then sends 4 of the remaining 5 save sets
> to the device
> that the first one was writing to. After mounting the other volume it
> sends the 6th and last save set to that device.
>
> I suppose it's conceivable that it was just coincidence and that it took
> it that long to figure out what it wanted to back up? I didn't think
> it generally mattered when running fulls even if a lot of files are
> involved? Anyway, assuming not, why the heck did it have to wait until
> it had another appendable tape to send more save sets to the first one
> if the first device was only running 1 session?
I have a laptops-noon group and pool that represents that kind of
behavior pretty consistently (with 6.0.2 and 7.2.1.) In your tests, you
said there were available devices -- were there also available writable
media in that pool (even if the one you had in the jukebox was
read-only?) In my environment, with drive parallelism set to 16 and
server parallelism more than that (32?), I've noticed that having >1
tape in the jukebox for my laptop pool makes the savegroup process
faster. It's not uncommon for one drive to spool up, have two or three
sessions writing to it, and no other sessions will be started until a
second drive is loaded, which gets a few itself, and then it continues
streaming the rest of the sessions to one or two drives. I notice this
because these are our lunchtime time-sensitive backups, and I'm normally
around to watch them. They're also a much smaller group than our
nightly backups; maybe 30 savesets total, presuming all of the laptops
are online.
My best guess is that during the initial session-to-device allocation
setting, Networker guesses drives and tapes and makes up its mind that
certain sessions are going to go to certain tapes -- even if the
configuration of the jukebox/inventory/drives don't make that practical.
And it doesn't update that allocation unless it has to, such as all of
the allocated sessions to one tape/drive are exhausted and it needs to
refresh. I've seen that behavior alot.
I've fixed the behavior, or at least made it better, by adding another
pool tape to the jukebox so it can always load >1. It's not the most
efficient, but it makes Networker happy. Second, because I have
external drives not part of the jukebox, either disabling them or making
sure the pool's only writable tapes are in the jukebox has helped some
too. I think that hardware combination (in addition to the jukebox
supply,) adds to the confusion in my installation, since Networker
doesn't know that I wouldn't immediately shove a laptop pool tape in the
external drive when it asks/plans for it. In any of the cases where I
make changes that Networker isn't expecting, (ie: don't put a tape in
where it expects,) it doesn't "take" right away and needs to either
timeout or finish some sessions before it redistributes them.
Bug? I dunno. Quirky behavior? Sure. Worth the time and effort to
explain it to an EMC rep who would be able to give some insight to why
Networker does what it does? I didn't bet on it.
Hope that helps,
Dave
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
