That is correct. This is why I am confused.
Files being stored FROM are on the AutoRAID. "Should" be exactly the same
file set under both types of store. Any control files being written to the
AutoRAID "should" be exactly the same for both types of store. AutoRAID
settings are identical between both types of store. There "should" be no
difference related to the AutoRAID
The only difference "should" be the location of the file being stored TO. In
the first case, the store is writing to a DAT3 off the MFIO SCSI channel (2
hours). In the second case, the store is writing to a non-system volume set
on the same MFIO SCSI channel (3.5 hours). The output of the store is NOT
being written to the AutoRAID in either case.
FYI: The non-system volume set is (4) 2GB and (1) 4GB standard SCSI disc
drives. Once the store to disc is complete, the final store file set is 4.8
GB (19671168 Sectors). Split into 4 files.
Looking at these resulting files I may have answered the question myself. I
would still like opinions as to whether this is likely to be the cause.
According to the manual, Orbit Backup/iX allocates disc space for a
store-to-disc file set in 65 sector chunks. In other words for a store to
disc of this size it would have done 302,634 allocations.
A listing of the resulting files appears to disagree with this
documentation. It shows "only" 9902 extents. Or allocation happening in
approximately 1986 sector chunks.
Either way, even at the lower number this would be a disc allocation every
1.27 seconds. Would this be a significant performance impact?
At the higher number it would be a disc allocation every 0.04 seconds. This
I would think would be a crippling performance impact.
The MPEX listf,2 follows. If anyone can help out confirming what these
numbers are telling me, it would help.
%listf @.bkup.sys,2
MPEX/3000 31N20512 (c) VESOFT Inc, 1980 6.0 03:05856 For help type
'HELP'
MPEX %LISTF @.bkup.sys PAGE 1
SYSTEM IPM_A TIMA,OPERATOR.SYS,OPER MON, MAR 3, 2003, 9:55 AM
ACCOUNT= SYS GROUP= BKUP
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
--DAYS--
SIZE TYP EOF LIMIT R/B SECTORS #X MX ACC
MOD
FULL0000 PRIV 8192W FB 4574 131071 1 292864 146 * 3
4
FULL0001 PRIV 8192W UB 131072 131072 1 8388608 4228 * 4
4
FULL0002 PRIV 8192W UB 131072 131072 1 8388608 4255 * 3
3
FULL0003 PRIV 8192W UB 40642 40642 1 2601088 1273 * 3
3
GROUP TOTAL: 4 FILES 4803 MEGABYTES 19671168 SECTORS
The detail device/sector map for these files is thousands of lines long, so
I will not include it here.
I appear to be unable to use file equations to change the default allocation
characteristics for these store files. When I try it, Orbit Backup/iX gets a
pile of error messages and aborts. I am working with Orbit technical support
to see if there is any way to change this behaviour. But I would also
appreciate any suggestions from HP3000-L on things to try to correct this.
Thanks for all the help so far.
Timothy Atwood
Holtenwood Computing
http://www.holtenwood.bc.ca/computing/
for Domtar Vancouver Mill
(Opinions expressed are mine and do not reflect Domtar)
-----Original Message-----
From: Craig Lalley [mailto:[log in to unmask]]
Sent: Monday, March 03, 2003 8:54 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] Disc Slower than DAT3 ?
--- [log in to unmask] wrote:
> A quick guess is that you are using the 12H Autoraid without the ARM
> utilities
> in performance mode. The 12H is slow due to raiding the drives. The 12H
gives
> you protection against disk failure but you pay on performance.
>
> Store to disk with autoraid as you have noticed is not going to improve
> unless
> you put the drives in "performance mode" in a non-protected array.
> My advise would have been to mirror disks vs raid.
> YGWYPF "you get what you pay for"
>
Joe,
I thought the same thing, until I re-read the inital problem. Tim is
reading
from the autoraid and writing a different volume set.
I am assuming the volume set was not on the auto-raid.
So is it? Tim?
-Craig
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
