From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] dumb question Message-ID: <20020626150713.A10838@cnm-vra.com> References: <171e27d5f2cfd12a9303117e58818e5b@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from astitt@cats.ucsc.edu on Wed, Jun 26, 2002 at 11:27:07AM -0700 From: Micah Stetson Date: Wed, 26 Jun 2002 15:07:13 -0700 Topicbox-Message-UUID: bad0d292-eaca-11e9-9e20-41e7f4b1d025 > Im sorry if im sounding like a troll, or if it seems like im flaming, but > seriously, whats up with this? ive no problem anymore with cp being as > simple as it is, in fact I like that idea, but i hold efficiency high > also. My soon to be plan 9 network isnt made of superfast zigahertz cpus. > Alternative OS's are my hobby, that said im not a funded computer lab, i > do this in my spare time with computers Ive salvaged and inherited. That > said maybe you wont notice how long it takes on a superfast computer, but > on older slower computers its unacceptable. Of course if we simply pass > off the idea of efficiency with the excuse that computers are getting > faster is no excuse, 300 mhz used to be undreamed of speed, but now we've > given way to in-efficient, kludged together solutions, and computers > appear no faster now then they did 10 years ago. anyways, im done ranting. > tar |tar no matter how you want to argue it is not a particularly > efficient or simple solution. In an effort to debunk this paragraph, I ran a few tests. I used kenji's cpdir and rsc's dircp to copy a directory tree of about 100M both locally and remotely. I've only run the tests a couple of times, but the numbers didn't vary much. Here are the numbers for the few tests I ran, the local machine is a 633Mhz Celeron running 4th Ed., the remote is a 120Mhz Pentium running u9fs on Linux (I don't have a real fileserver). I don't this this network can be accused of using 'zigahertz' equipment. 8.out is Kenji's cpdir. Local kfs -> Local kfs ---------------------- term% time 8.out doc foo 0.56u 13.48s 338.82r 8.out doc foo # status= main term% time 8.out doc foo 0.50u 14.08s 338.56r 8.out doc foo # status= main term% time dircp doc foo 2.39u 37.37s 316.66r dircp doc foo term% time dircp doc foo 2.55u 37.41s 322.92r dircp doc foo Local kfs -> Remote u9fs ------------------------ term% time dircp doc /n/cephas/home/micah/foo 1.45u 27.48s 425.44r dircp doc /n/cephas/home/micah/foo term% time dircp doc /n/cephas/home/micah/foo 1.11u 27.33s 421.52r dircp doc /n/cephas/home/micah/foo term% time dircp doc /n/cephas/home/micah/foo 1.58u 26.71s 422.80r dircp doc /n/cephas/home/micah/foo term% time 8.out doc /n/cephas/home/micah/foo 0.10u 7.72s 119.46r 8.out doc /n/cephas/home/micah/foo # status= main term% time 8.out doc /n/cephas/home/micah/foo 0.12u 7.75s 117.92r 8.out doc /n/cephas/home/micah/foo # status= main Remote u9fs -> Remote u9fs -------------------------- term% time /usr/micah/8.out foo bar 0.17u 6.58s 163.85r /usr/micah/8.out foo bar # status= main term% time dircp foo bar 1.43u 33.91s 730.83r dircp foo bar I was floored. I haven't any clue why dircp is so slow. But I knew the arguments against using archive programs connected with a pipe were unjustifiable, so I rewrote dircp to use mkfs and mkext: #!/bin/rc switch($#*){ case 2 # mkfs is too chatty, is there a quiet mode? @{cd $1 && disk/mkfs -a -s . <{echo '+'} >[2]/dev/null}|@{cd $2 && disk/mkext -d . >[2]/dev/null} case * echo usage: dircp from to >[1=2] } And here are my results with this (calling it mydircp): Local kfs -> Local kfs ---------------------- term% time mydircp doc foo 3.44u 19.44s 240.70r mydircp doc foo That's about 30% faster than cpdir (real time). Remote u9fs -> Remote u9fs -------------------------- term% time mydircp foo bar 2.23u 13.54s 273.04r mydircp foo bar This one's 66% slower than cpdir (don't know why), but it's a good even and a half MINUTES faster than the tar version. Local kfs -> Remote u9fs ------------------- term% time mydircp doc /n/cephas/home/micah/foo 2.41u 12.14s 68.08r mydircp doc /n/cephas/home/micah/foo term% time mydircp doc /n/cephas/home/micah/foo 2.70u 12.55s 67.56r mydircp doc /n/cephas/home/micah/foo Here's the gem. I think this takes real advantage of having two communicating processes. It's nearly twice as fast as cpdir and six or seven times as fast as dircp. My question is, is there a reason to use tar over mkfs/mkext, and why is tar so slow? Also, does anyone have an explanation for why Remote->Remote is slower with mydircp while Local->Remote is so much faster? Micah