HP3000-L Archives

January 1997, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jim Hawkins <[log in to unmask]>
Reply To:
Jim Hawkins <[log in to unmask]>
Date:
Thu, 30 Jan 1997 10:54:43 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
Terry Prime wrote:
> When the turbostore is run in parallel mode it takes half as long again to
> complete, and uses extra DDS tapes.  For example in sequential mode an
> incremental backup will use 2 DDS tapes and take about one and a half hours
> to complete.  When run in parallel mode it takes over two and a quarter
> hours and uses 3 DDS tapes.  Also, eventhough LDEV8 is the first device, it
> always requests that the third tape be mounted on LDEV9 the second device.
> Why doesn't it request the third tape on LDEV8 which is free at the time -
> LDEV8 has usually be unloaded long before LDEV9 is full?
>
> I would have thought that parallel mode should have been a lot faster
> because it is writing to both devices at the same time.  Anybody have any
> suggestions?

There are a lot of things that you leave out (where are the disks?
INTERLEAVE? COMPRESSION?) that might change the answers but here goes:

For performance: While you mention that the tapes are on separate HP-IB
channels you don't say where the disks are.  I suspect you have some
HP-IB channel I/O bottlenecks and the longer times are likely due to
more contention on the HP-IB bus -- HP-IB performance can be adversely
effected if "too many" devices attempt to talk at the same time.  In the
case of your parallel option STORE will generate, on average, two times
as many I/O across all of your disks and INTERLEAVE can increase this
further
by doing I/O to multiple files at a time.

For capacity: I assume that your back-up nearly fills up the 2 DDS tapes
in serial mode.  When STORE divides up the files for parallel store it
makes a quick estimate of file numbers and sizes and tries to spread
them evenly across the two devices but it cannot split a file between
the sets.  It is not uncommon, especially if you're storing large files,
for STORE to "over fill" one pool and "under fill" another (in
relationship to the size of a tape).   This is even more possible with
COMPRESSION options as even if two files are the same size they will
compress to different sizes -- STORE can't know in advance what the
compression ratio will be as the LZ algorithm efficiency is based upon
the file contents.
Regards,


Jim
My opionions/mistakes not my employer's.

ATOM RSS1 RSS2