coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[coreutils] [Bug 591969] Re: dd: cryptic error message when bs=<unreason


From: Jim Meyering
Subject: [coreutils] [Bug 591969] Re: dd: cryptic error message when bs=<unreasonably large value>
Date: Mon, 14 Jun 2010 10:43:36 +0200

Imre Péntek wrote:
> vasárnap 13 június 2010 23:23:39 dátummal Ön az alábbiakat írta:
>> Making dd give a better diagnostic for e.g., "bs=3G" on an i686
>> system might be more work than it's worth.
> Well, this way it's okay that dd does not accept 3G as block size, but then
> man dd would document that according to the appropriate behavior.
> Like this:
> BYTES may be followed by the following multiplicative suffixes: c =1, w =2,
> b=512,  kB  =1000,  K  =1024,  MB  =1000*1000,  M=1024*1024,  xM =M
> GB=1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y.
> The same applies to BLOCKS with the practical exception your
> machine(?)/kernel(?)/... needs to be able to allocate memory for (at
> least(???)) one(?) block, so, you can expect not to be able to use block sizes
> greater or equal to 2G on a 32 bit architecture, and 16E on a 64 bit
> architecture.
>
> or something like this. what I read now in man dd is a partial documentation
> which would (and had) me expect bs=3G to be OK in all cases, however it isn't
> ok in my case.

Thanks for the suggestion, but we can't use that, since
dd --help content has to stay small and generally relevant.
[btw, the man page is generated from dd --help's output. ]
Using such large buffer sizes is neither common nor worth
documenting in a place like --help.

To improve the "real" documentation -- that's always welcome --
you would add to "info dd" (patch doc/coreutils.texi in the sources)
saying something like "Any block size you specify via bs=, ibs=, obs=, cbs=
should not be too large --- values larger than a few megabytes
are generally wasteful or (as in the gigabyte..exabyte case) downright
counterproductive or error-inducing."

While I deliberately do not mention the actual limits above,
note that they're about half of the numbers you listed: ~1GiB and ~8EiB

I went ahead and wrote the patch:

>From d8e0d2d0efba4fa9c5bc1c29bf7e0028dd292237 Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Mon, 14 Jun 2010 10:15:57 +0200
Subject: [PATCH] doc: dd: discourage use of very large block sizes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/coreutils.texi (dd invocation): Warn against using a very large
block size.  Suggested by Imre Péntek.
---
 doc/coreutils.texi |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 26b4eba..102ceaf 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8020,6 +8020,11 @@ dd invocation
 @samp{w}=2, @samp{x@var{m}}=@var{m}, or any of the
 standard block size suffixes like @samp{k}=1024 (@pxref{Block size}).

+Any block size you specify via @samp{bs=}, @samp{ibs=}, @samp{obs=}, 
@samp{cbs=}
+should not be too large---values larger than a few megabytes
+are generally wasteful or (as in the gigabyte..exabyte case) downright
+counterproductive or error-inducing.
+
 Use different @command{dd} invocations to use different block sizes for
 skipping and I/O@.  For example, the following shell commands copy data
 in 512 KiB blocks between a disk and a tape, but do not save or restore a
--
1.7.1.511.g2f531



reply via email to

[Prev in Thread] Current Thread [Next in Thread]