Scratch that. Orbit says FCONTROL is only called twice. Once when the file
is first opened and second when the file is closed.
So, can anyone out there explain to me why a Mapped Access file would be so
inefficient?
As a test I created a regular fixed length file of the same size and used
regular FWRITE calls to write a bunch of dummy records to it. Much more
efficient than the Mapped IO files coming out of Orbit Backup/iX.
All the documentation I can find says Mapped IO should be more efficient
than standard file intrinsics. Yes, Long Mapped is less efficient then Short
Mapped. But the documentation I have found would claim it is still more
efficient than regular file intrinsics. The only caveat in the HP
documentation is if FCONTROL(2) is called too often to post the data or
FCONTROL(6) is called too often to update the EOL.
As far as either Orbit Tech Support or I can figure out, it should be the
memory manager controlling how this file gets allocated. Memory manager on
6.0 PP2. So why would the memory manager do this? Would it be related to too
little memory? Page faults?
The following MPEX Listf,2 was done just as a partial backup started. The
FULL0001, 2 & 3 files are the backup files created from the previous night's
full backup. The PART0001 file is the one just created seconds before by a
partial backup starting.
/%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, 11:54 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
PART0001* PRIV 8192W UB -131072 131072 1 512 2 *
1 reader, 1 writer
GROUP TOTAL: 5 FILES 4803 MEGABYTES 19671680 SECTORS
Note how the FULL000# files are split into a huge number of extents. If one
does an MPEX listf,4 the listing goes to about 3400 lines at three physical
addresses per line. So it really does appear all those extents above really
were separate disc allocations. Well over 9,000 separate disc allocations
with all the overhead that entails.
%listf [log in to unmask],2
MPEX %LISTF [log in to unmask] PAGE 1
SYSTEM IPM_A TIMA,OPERATOR.SYS,OPER MON, MAR 3, 2003, 12:01 PM
ACCOUNT= SYS GROUP= BKUP
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
--DAYS--
SIZE TYP EOF LIMIT R/B SECTORS #X MX ACC
MOD
PART0001* PRIV 8192W UB -131072 131072 1 121024 64 *
5 readers, 5 writers
Seven minutes later, a similar listf shows the memory manager (or Orbit
Backup/iX) has already allocated an additional 62 extents to the partial
backup mapped access file. All for small chunks. Any idea why?
A DISCFREE indicates the drives are not fragmented at all. Almost 100% of
the space is in very large contiguous chunks. So fragmentation can not be
the reason.
The discfree that shows this follows:
discfree
DISCFREE A.50.01 Copyright (C) Hewlett-Packard 1992. All rights reserved.
MON, MAR 3, 2003, 12:07 PM
Syntax is: DISCFREE [<format>][,<ldev>][,<vsname>]
Where <format> is one of the following:
A, HISTOGRAM, 1: to see a histogram.
B, ALLOCATION, 2: to see disc allocation.
C, ALLOCATION2, 3: to see disc allocation format 2.
D, SUMMARY, 4: to see disc allocation summary.
E, SUMMARY2, 5: to see disc allocation summary format 2.
Where <ldev> is the logical device number of a disc.
Enter [<format>][,<ldev>][,<vsname>] : a,,USER_VOL_SET_1
----------------------------------------------------------------------------
---
LDEV : 11 -- (USER_VOL_SET_1:USER_1_A)
LARGEST FREE AREA: 4912896 TOTAL FREE SPACE: 4914304
0 BLOCK(S) OF 1- 9 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 10- 99 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 100- 999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
1 BLOCK(S) OF 1000- 9999 CONTIG. SECTORS = 1408 FREE SECTORS.
0%
0 BLOCK(S) OF 10000- 99999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
1 BLOCK(S) OF 100000-AND UP CONTIG. SECTORS = 4912896 FREE
SECTORS.100%
----------------------------------------------------------------------------
---
LDEV : 12 -- (USER_VOL_SET_1:USER_1_B)
LARGEST FREE AREA: 4836208 TOTAL FREE SPACE: 4836208
0 BLOCK(S) OF 1- 9 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 10- 99 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 100- 999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 1000- 9999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 10000- 99999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
1 BLOCK(S) OF 100000-AND UP CONTIG. SECTORS = 4836208 FREE
SECTORS.100%
----------------------------------------------------------------------------
---
LDEV : 13 -- (USER_VOL_SET_1:USER_1_C)
LARGEST FREE AREA: 4830832 TOTAL FREE SPACE: 4830960
0 BLOCK(S) OF 1- 9 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 10- 99 CONTIG. SECTORS = 0 FREE SECTORS.
0%
1 BLOCK(S) OF 100- 999 CONTIG. SECTORS = 128 FREE SECTORS.
0%
0 BLOCK(S) OF 1000- 9999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 10000- 99999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
1 BLOCK(S) OF 100000-AND UP CONTIG. SECTORS = 4830832 FREE
SECTORS.100%
----------------------------------------------------------------------------
---
LDEV : 14 -- (USER_VOL_SET_1:USER_1_D)
LARGEST FREE AREA: 4830832 TOTAL FREE SPACE: 4830832
0 BLOCK(S) OF 1- 9 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 10- 99 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 100- 999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 1000- 9999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 10000- 99999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
1 BLOCK(S) OF 100000-AND UP CONTIG. SECTORS = 4830832 FREE
SECTORS.100%
----------------------------------------------------------------------------
---
LDEV : 15 -- (USER_VOL_SET_1:USER_1_E)
LARGEST FREE AREA: 9729584 TOTAL FREE SPACE: 9729584
0 BLOCK(S) OF 1- 9 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 10- 99 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 100- 999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 1000- 9999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
0 BLOCK(S) OF 10000- 99999 CONTIG. SECTORS = 0 FREE SECTORS.
0%
1 BLOCK(S) OF 100000-AND UP CONTIG. SECTORS = 9729584 FREE
SECTORS.100%
/
-----Original Message-----
From: Atwood, Tim (DVM)
Sent: Tuesday, March 04, 2003 12:08 PM
To: [log in to unmask]
Subject: RE: [HP3000-L] Disc Slower than DAT3 ?
Thanks for all the help so far.
Evidence so far is pointing to too frequent disc allocations.
The Orbit Backup disc store files are accessed Mapped IO. (Long Mapped
apparently since they end up 2GB each). So far I am guessing Orbit is simply
calling FCONTOL(2) to post the data much too frequently. Orbit technical
support is looking into this.
In the mean time, any other suggestions? I am not very familiar with
accessing files with Mapped Access. Any suggestions on how to reduce how
often a new extent is allocated to such a file? A lot of the normal file
stuff I know about appears to work different on Mapped files.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
