[comp.unix.ultrix] Slow dump/restore of ra90s on DECsystem 5810

mf@ircam.fr (Michel Fingerhut) (11/03/90)

Having had disk problems on ra90s, we had one replaced.  So as to copy the
file systems from the old one to the new one, we ran a dump of each fs in
the old one piped into a restore on the corresponding fs on the new one.
This was run in single user mode, and single jobs: nothing done in parallel.

It took an incredible long time to perform: for a 500 Meg partition -- over
2.5 hours.

Does anyone have a clue as to why?  Disk performance, controler management of
accesses to different drives, pipe problem or what?

Thanks for any help,
Michael Fingerhut

karrer@ethz.UUCP (Andreas Karrer) (11/04/90)

mf@ircam.fr (Michel Fingerhut) writes:

>Having had disk problems on ra90s, we had one replaced.  So as to copy the
>file systems from the old one to the new one, we ran a dump of each fs in
>the old one piped into a restore on the corresponding fs on the new one.
>This was run in single user mode, and single jobs: nothing done in parallel.

>It took an incredible long time to perform: for a 500 Meg partition -- over
>2.5 hours.

  I just did that on a DECsystem 5840 (3 RA90's on one kdb50) with: 

    /etc/dump 0f - /dev/rra1d | /etc/restore rf -

  /dev/rra1d is 144518 kB, 97439 used. It took 14 min 12 sec. That would
  make about 50 mins for your 500 Megs. Did you specify the raw device?
  Come to think of it - we initially had problems with partitions that
  were not an integral multiple of the cylinder size. You should probably
  check (chpt -q) if all your ra90 partitions are a multiple of
  13tracks*69sectors*512bytes. DEC's defaults are set up this way.

  BTW, i do not think that the 14:12 are FAST - it makes about 115 kB/sec.
  Disk transfer rates (reported by iostat) never got higher than 247 bps,
  but the cpu's were only lightly loaded. 

  If I dump to an exabyte (emulates TU81, on klesi-b vaxbi adapter), using

    /etc/dump 0dsf 1600 90000 - /dev/rra1d | buffer -s 126b > /dev/nrmt0h

  I get about 210 kB/sec, which still does not bring the tape to streaming mode.

>Does anyone have a clue as to why?  Disk performance, controler management of
>accesses to different drives, pipe problem or what?

  I think the kdb50/ra90 combination is just lousy. Here some timings from
  copying a 10M file from one disk to another (/bin/time cp FROM TO):

	machine          disks                  real     sys

	Convex C 220     NEC D2363 VME           2.5     2.1 sec
	Sun 4/490        Sabre 1150 IPI          4.9     2.9
	DECsystem 5840   DEC RA 90              29.0    13.4
	Sun 3/280        CDC Eagle SMD          33.4    12.9
	DECsystem 5400   DEC RA 90              37.3    10.5
	DEC VAX 11/785   DEC RA 81              41.4    25.1

  (all systems very lightly loaded). The comparison with the Convex is not
  fair, since it costs quite a bit more. However, the Sun 4/490 _does not_.
  The last line shows that the i/o performance of DEC machines did not 
  increase dramatically over the years...

>Thanks for any help,
>Michael Fingerhut

  not much of a help - oh well...
+------
  Andi Karrer, Communication Systems, ETH Zuerich, Switzerland.
  karrer@ks.id.ethz.ch                   karrer@czheth5a.bitnet