On Fri 07 Feb 2020 at 11:24:46 (-0500), Gene Heskett wrote: > On Friday 07 February 2020 10:20:45 David Wright wrote: > > > On Fri 07 Feb 2020 at 08:12:18 (-0500), Gene Heskett wrote: > > > I was trying different ways to move a kernel src to the pi for > > > making and also reached the conclusion that mc was for some reason > > > terminally slow at unpacking an .xz kernel and writing the unpack > > > across the network. It was promising me a 43+ hour ETC. And was > > > showing figures when it updated the screen here as 4.3 > > > kilobytes/second? Really? > > > > Ooh, gosh, don't do that! Even with a cat5 cable between two machines, > > ¹unpacking an archive across the link with mc¹ will take at least 100x > > more than ²transferring the archive and unpacking at the destination², > > even if you do said unpacking with mc. > > you miss-understood, both the archive and mc were on this machine and > only the output of the unpack was going out over the cat5.
Yes, that's what I described in ¹… …¹, and it's slow. AIUI mc sends the filename and stat information across the link (so that the other end knows where to put it, and what metadata to use), then it sends the file (which is usually much larger). When the other end indicates that the file arrived, mc starts on the next file. > > fish is fine for the odd file transfer, and I guess it's faster than > > kermit (untested), but there's a large overhead on each file. > > I don't use fish that I know of. Thats not to say mc isn't using it. In > which case someone has been playing with mc that has no clue what they > are doing. If you're not running any suitable server at the other end (are you?), then instead of the first line of /usr/lib/mc/fish/* telling a fish server what to do, the script is handed to bash, which ignores that first line (# comment) and executes the shell commands instead. Those echo lines in the scripts are what would be the fish server's return codes going back to mc. > > > So I stopped that, killed the partial copy, backed out and copied > > > the whole image to the pi in just 2 or 3 minutes, with mc, then > > > unxz'd it on the pi in maybe 3 minutes. Yes, you then used ²… …² above which is fast because mc only has to deal with sending a single, smaller (compressed) file. > > > So maybe bit rot in mc? DIIK. > > > > Take a look at the scripts in /usr/lib/mc/fish/ and imagine running a > > couple of them on each and every file in the kernel. > > According to the README.fish, there, mc does use the scripts in that > directory. But fish itself is not installed. > > Perhaps it should be? And the slowness is because its not? Another DIIK. I'm not aware that there's a faster way of sending the files once you've unpacked the archive locally. After all, you've thrown away the benefits of compression and aggregation. Cheers, David.
