9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Steve simon <steve@quintile.net>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] dd(1) takes very long
Date: Fri, 1 Mar 2024 10:37:24 +0000	[thread overview]
Message-ID: <254FA221-AFDF-4D5F-9A54-C5D9DEC7E3B5@quintile.net> (raw)
In-Reply-To: <CAJQ9t7jJHBNh=cG71Pf0LCZS+LccuPU9Hfv+kJ=Oe3cHX1F8NA@mail.gmail.com>

A larger block size as lucio says, and also try two dd's with a pipe between them,
one reading and one writing. dd(1) is single threaded but you have two asynchronous physical devices.

I have had good success copying sd-cards using fcp -  rsc's  multithreaded cp, already in the distribution,
though I don't know what blocksize it uses offhand.

-Steve

> On 1 Mar 2024, at 09:39, Lucio De Re <lucio.dere@gmail.com> wrote:
> 
> Increasing the dd block size (-bs 1024k or as big as the man pages
> allow) could make a big difference.
> 
> 
> On 3/1/24, Aleksandar Kuktin <ak@triklod.rs> wrote:
>>> On Fri, 1 Mar 2024 10:08:25 +0100
>>> Marco Feichtinger <marco@germteig.com> wrote:
>>> 
>>>> and the computer isn't a SBC bitty box, the transfer rate is weirdly
>>>> low.
>>> 
>>> Well, both disk are on the same machine.
>>> It's a Supermicro X7SPA-H-D525 board.
>>> 
>>> -marco
>> 
>> Well, that's not a bitty box. Wish I bought something like that instead
>> of my BananaPi. Anyway, someone more knowledgeable on Plan 9 than me is
>> needed. I can only speculate that the OS and hardware fight. I have
>> something similar happening on my desktop with modern hardware running
>> old software. I run GNU/Linux on it. For some reason I can't figure out,
>> transfers start off normal but then degrade to 10 Mbps or less after a
>> few GiB are transferred. If I try it with CentOS 7, it runs fine. But
>> when I use my own homegrown distro it's pathologic. Kernel version
>> 3.16.85, vanilla.
>> 
>> --
>> Svi moji e-mailovi su kriptografski potpisani. Proverite ih.
>> All of my e-mails are cryptographically signed. Verify them.
>> --
>> You don't need an AI for a robot uprising.
>> Humans will do just fine.
>> --
>> 
> 
> 
> --
> Lucio De Re
> 2 Piet Retief St
> Kestell (Eastern Free State)
> 9860 South Africa
> 
> Ph.: +27 58 653 1433
> Cell: +27 83 251 5824



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T0fd6444acb9c7811-Mb5849711471b91fba2a419ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

  reply	other threads:[~2024-03-01 10:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01  8:24 Marco Feichtinger
2024-03-01  8:53 ` Aleksandar Kuktin
2024-03-01  9:08   ` Marco Feichtinger
2024-03-01  9:35     ` Aleksandar Kuktin
2024-03-01  9:39       ` Lucio De Re
2024-03-01 10:37         ` Steve simon [this message]
2024-03-01 12:44           ` sirjofri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=254FA221-AFDF-4D5F-9A54-C5D9DEC7E3B5@quintile.net \
    --to=steve@quintile.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).