From owner-freebsd-doc@freebsd.org Wed Jun 10 07:22:02 2020 Return-Path: Delivered-To: freebsd-doc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7033232C080 for ; Wed, 10 Jun 2020 07:22:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49hdj62Sgtz4pFk for ; Wed, 10 Jun 2020 07:22:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 52BBA32BDAA; Wed, 10 Jun 2020 07:22:02 +0000 (UTC) Delivered-To: doc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5287332BBBE for ; Wed, 10 Jun 2020 07:22:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49hdj61ZmRz4p5K for ; Wed, 10 Jun 2020 07:22:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 31839234A0 for ; Wed, 10 Jun 2020 07:22:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 05A7M2oe001283 for ; Wed, 10 Jun 2020 07:22:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 05A7M2mr001257 for doc@FreeBSD.org; Wed, 10 Jun 2020 07:22:02 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: doc@FreeBSD.org Subject: [Bug 247136] Handbook, section 2.3.1.1: dd(1) command uses "bs=1M" (slow), should be "bs=4k" (/much/ faster) Date: Wed, 10 Jun 2020 07:22:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Documentation X-Bugzilla-Component: Documentation X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: t.eichstaedt@gmx.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: doc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 07:22:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247136 Bug ID: 247136 Summary: Handbook, section 2.3.1.1: dd(1) command uses "bs=3D1M" (slow), should be "bs=3D4k" (/much/ faster) Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: Documentation Assignee: doc@FreeBSD.org Reporter: t.eichstaedt@gmx.net Dear documenters, 1. unless there's any technical reason to use a blocksize of 1M, this shoul= d be changed. Unfortunately I do not have the insight to judge that, so please check w/ s/o who knows more about this. All images I wrote w/ "bs=3D1k" so= far worked, so I'd assume that either all those images were integer multiples of 1M, or there's no technical reason to pad the end w/ zeroes to the next 1M boundary. Rationale: (AFAIK) The native blocksize of USB media is 4k. Writing an image w/ the native blocksize is about 7 times faster (at least on USB 2). 2. I'd like to suggest to add "status=3Dprogress" to the dd(1) arguments, b= ecause this command can take a few minutes (on USB 1/2) and it's much nicer to have some reply about what's going on. Somehow like this: "older versions of dd= (1) do not support 'status=3Dprogress'. If it fails, simply use the command w/= o it." I just stumbled over this when I was preparing the media for an installatio= n, and instead of just doing what I used to do ("dd bs=3D1k conv=3Dsync"), I c= hecked the handbook to see if s/th changed. Nothing changed, but using "bs=3D1M" = was significantly slower than "bs=3D1k". So I thought: both is wrong, should b= e 4k!=20 And yes - using "bs=3D4k" is in fact much faster. The same bad example occurs in the man page of dd(1) (last example) With kind regards, Torsten --=20 You are receiving this mail because: You are the assignee for the bug.=