Boy, you guys (and gals) never disappoint. I got a whole slew of replies
to my posting. I posted two questions to problems I had already worked
around, without entirely understanding the answers.
The second, but easier to resolve, was:
> I tar'd all the files on the disk to tape, switched disks, rebooted from
> CD-ROM, tar'd the files to the new disk, installed the boot block, and
> rebooted. What happened? It hung at the point where init turns control
> over to /etc/rc (i.e. right after root on... swap on... dump on...).
> Somebody suggested that I dd the old /dev/sd0a to tape, and then dd it back
> to the new disk. I did that, and then discovered that I also had to
> recover the old disk type and label manually. Once I did that, too, the
> system came up just fine, no hanging or anything. What's different between
> dd and tar that would cause this behavior??
This was easy: apparently, (and I should have known this!) tar doesn't
preserve devices, not to mention empty directories and sockets.
Most of the recommendations were to use dump/restore, although one hearty
person suggested cpio. A number of others said to use dd, but of course,
dd also overwrites the disk label and partition map. In the end, I *did*
use dd, overwriting the label and map, and then manually restoring them via
format, and newfs'ing the partitions. Next time, I'll use dump/restore!
Thanks to all of the following respondants, and apologies for no personal
replies...
kuno@mail3.engin.umich.edu
Stephen Malowany <malowany@cenparmi.concordia.ca>
mitch@cirrus.com (Mitch Wright)
Russell Ruby <russ@MATH.ORST.EDU>
Paul Allen <paula@atc.boeing.com>
danny@ews7.dseg.ti.com
bcook@Kodak.COM (Bill Cook)
zeke@mpl.UCSD.EDU (Rob Scott)
Chris Keane <chris@rufus.state.COM.AU>
matt@wbst845e.xerox.com (Matt Goheen)
Steve Mowbray <sm@gec2.physics.manchester.ac.uk>
gdmr@dcs.edinburgh.ac.uk
Dave Mitchell <D.Mitchell@dcs.sheffield.ac.uk>
Gary Blumenstein <garyb@gcm.com>
mikem@ll.mit.edu (Michael J Maciolek)
"Robert Lane A." <lar@ucs.usl.edu>
"John Paul O'Brien" <john@solar.nova.edu>
Gustavo Vegas <gustavo@davinci.concordia.ca>
Mark Ferraretto <mferrare@physics.adelaide.edu.au>
The first, but trickier, question was:
>- We have been having tremendous problems getting the proper level of
> throughput across of data link between New York and London. The line runs
> at 32KB (switching to 48KB at night). In spite of that, we were
> consistently seeing transfer rates (via rcp and ftp) of 1.6 to 1.8 kb/sec.
> We accidently discovered that if we login to the remote site, and pull the
> data across (i.e. an ftp get), rather than pushing it (i.e. an ftp put) we
> got throughput levels that slightly exceeded our expectations (i.e. 3.3 to
> 3.4 kb/sec). Furthermore, we see this no matter which direction we send
> the files. Pulls are always about twice as fast as pushes. WHY??
This is VERY strange. We first discovered the transfer rate problem
accidentally, when my DB administrator did an rcp in the opposite
direction, and got a full-speed transfer.
So, I decided to automate the timing process, by writing a shell script
that does a date, an rcp of the same file each time, and another date.
Then I used Lotus to do all my calculations, and graph the results. Over
the last few days, we are consistently seeing different results than I
originally reported! All traffic to New York, regardless of whether it is
pushed or pulled, goes over the line at full speed (3.4 - 3.5 kb/sec).
London-bound traffic doesn't want to go faster than about 1/2 the upper
limit (i.e. 1.5 - 1.7 kb/sec).
When we switch the line speed up to 48KB, the NY-bound transfers' speed
increases to 5.05 - 5.2 kb/sec, and the London bound stuff increases
slightly, up to about 1.8 - 2.2 kb/sec.
(We considered ocean currents and trade winds, but later dismissed them as
considerations...)
The machine in NY is a 4/670, and the one in London is a SPARCstation 2.
Both are running 4.1.2. Both machines are being used for other purposes,
but not in the middle of the night!
Replies to the first attempt at this question came from:
mikey@ccs.carleton.ca (Mike G McFaul)
Russell Ruby <russ@MATH.ORST.EDU>
fred@dip1.ee.uct.ac.za (Fred Hoare)
Gregory Higgins <higgins@math.niu.edu> (some humor, not so much help)
Gary Blumenstein <garyb@gcm.com>
Unfortunately, there was nothing quite as helpful in this batch.
If you can suggest anything different for the transfer issues, I'd be
grateful. Otherwise, we intend to get on the phone with our network
supplier (Newbridge) yet again, later today.
Thanks!
Evan
P.S. If you replied, and you didn't make the list, that's because it
arrived after I posted this. Sorry.
-- WHO: Evan L. Marcus || There is no truth to the rumor that WHAT: Fusion Services Group, Ltd. || Bill and Hillary Clinton plan to WHERE: New York, New York, USA || name their next children Soho and HOW: evan@fsg.com || Little Italy.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:45 CDT