From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 1C45C15803E for ; Thu, 4 Jan 2024 02:48:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E0A372BC06E; Thu, 4 Jan 2024 02:48:25 +0000 (UTC) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7885A2BC01F for ; Thu, 4 Jan 2024 02:48:25 +0000 (UTC) Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-6da47688fd9so38585b3a.0 for ; Wed, 03 Jan 2024 18:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704336504; x=1704941304; darn=lists.gentoo.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=YFVa0WgRp0qiXfzEbdhs6jHtGrgz/RdRpvZ226qd1+o=; b=Wo/yy2Sm3uH18mhA/sAVkD7CQk9wfkvi6bAhmC+0VqjIl/P+8eNtnyqACr2uFg6a/K be7ZrfhAUhXHEMUJLqt8TYkWrwCFUz0/JHUFQBfH8LvyiMZ7OlZRpLa17vXo5p2HWBaL TvV0D0eb0BcZaSzGAA/9XsZCx9Odt7kG3UuzcEZie5MvIbblSCV0zzdLDCe1AQs65kgs VYPESrm+J/eIUgd7FNyLkThKwbGVhH8NHggl1BwuWwS0ImU76hgA4NGO4CICb6OOjsvc nrL5+IBfOGAsK8E1lMEwDsLU82cocMUGbaq2iKM1dMWxjMDe2SNHgf05e7dyu14He4cX q2lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704336504; x=1704941304; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YFVa0WgRp0qiXfzEbdhs6jHtGrgz/RdRpvZ226qd1+o=; b=QUfKoKkIZBFU1ryJvanpAchvmdTjkJ0Kx2gtZETZy5jquzKLnVaBI+qPMSf+iTCYI1 EjfbI06NZo4v4ncJa11h0QgmtDVUHy5E3l6wyqbWDrErhHX45m8WQdiSUNSObrwLB31g FzFUelwAPgDILZJJw8JDh+uhfX6PZaQMUd+TdHyvP7dPAJltQnD66P6gcg26q/PO4L8/ 9Y0rvQAeUx7d4rvh4ygJ215eOl/Rzwg0ny00VkHKxxWClqCfmTsKWlGkCUkByZK+xbk7 QoUN7Yyp3AivqghZkP173I5Xoz+A3kbTPXuFyjDWu2tBCMHyqvbDVavNfOFzPBBLkRc5 5qCA== X-Gm-Message-State: AOJu0YxftdUoV5HGebus4m3F6pUhLTCxb2QyrLCIm88JC/eWeTW4jwnP fJcCHib9uixwlCGLz8GpQYvOlRSriJmP1B9/sXbZzO7De3Y= X-Google-Smtp-Source: AGHT+IFWmj223LuO7Ai79sbWAjjHXRHpQeH3UyLtOmW20BwlP3GbShQsr1FCcERPc11hmtS0AHsa4y/1fIIGya3Gg1o= X-Received: by 2002:a05:6a00:2b42:b0:6d9:a073:b21f with SMTP id du2-20020a056a002b4200b006d9a073b21fmr7858pfb.7.1704336504103; Wed, 03 Jan 2024 18:48:24 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <756b80e0-e195-2973-e9a1-75779d207138@gmail.com> <5743300.DvuYhMxLoT@cube> In-Reply-To: <5743300.DvuYhMxLoT@cube> From: Adam Carter Date: Thu, 4 Jan 2024 13:48:13 +1100 Message-ID: Subject: Re: [gentoo-user] LiveGUI USB Image To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary="000000000000e7a867060e15c348" X-Archives-Salt: 3fcbd505-64b9-4869-a290-b564ad6809c7 X-Archives-Hash: f7097f4bb1ebd3dbf1291f89e7adc9b4 --000000000000e7a867060e15c348 Content-Type: text/plain; charset="UTF-8" > > > dd if=/path/to/iso-image of=/dev/sd? bs=4M status=progress > > > > Replace the obvious bits. > > I've tried a few values of block size over the years, but so far I haven't > noticed any difference. I haven't run any proper tests though. > I think it's just that the default blocksize is (or was) very small (512 bytes?) so setting it to anything non-small helps a lot. eg one example (from https://superuser.com/questions/234199/good-block-size-for-disk-cloning-with-diskdump-dd#234204) seems to show that most gains are in by around 16k. There's probably a lot of testing noise in these results. $ ./dd_obs_test.sh block size : transfer rate 512 : 11.3 MB/s 1024 : 22.1 MB/s 2048 : 42.3 MB/s 4096 : 75.2 MB/s 8192 : 90.7 MB/s 16384 : 101 MB/s 32768 : 104 MB/s 65536 : 108 MB/s 131072 : 113 MB/s 262144 : 112 MB/s 524288 : 133 MB/s 1048576 : 125 MB/s 2097152 : 113 MB/s 4194304 : 106 MB/s 8388608 : 107 MB/s 16777216 : 110 MB/s 33554432 : 119 MB/s 67108864 : 134 MB/s --000000000000e7a867060e15c348 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> dd if=3D/path/to/iso-image of=3D/dev/sd? bs=3D4M status=3Dprogress
>
> Replace the obvious bits.

I've tried a few values of block size over the years, but so far I have= n't
noticed any difference. I haven't run any proper tests though.

I think it's just that the default blocksiz= e is (or was) very small (512 bytes?) so setting it to anything non-small h= elps a lot.

eg one example (from https://superuser.com/questions/234199/good-block-size= -for-disk-cloning-with-diskdump-dd#234204) seems to show that most gain= s are in by around 16k. There's probably a lot of testing noise in thes= e results.
$ ./dd_obs_test.sh
block size : transfer rate
       512 : 11.3 MB/s
      1024 : 22.1 MB/s
      2048 : 42.3 MB/s
      4096 : 75.2 MB/s
      8192 : 90.7 MB/s
     16384 : 101 MB/s
     32768 : 104 MB/s
     65536 : 108 MB/s
    131072 : 113 MB/s
    262144 : 112 MB/s
    524288 : 133 MB/s
   1048576 : 125 MB/s
   2097152 : 113 MB/s
   4194304 : 106 MB/s
   8388608 : 107 MB/s
  16777216 : 110 MB/s
  33554432 : 119 MB/s
  67108864 : 134 MB/s
--000000000000e7a867060e15c348--