Comment 4 for bug 591969

(Jim Meyering wrote, on the coreutils-bugs mailing list:

Dave Gilbert wrote:
> You're on 32bit, on 64bit this seems to work. My guess is that there is
> a limit to the block size available on 32bit (if that limit was 2G or
> just under it wouldn't surprise me), on 64bit there is a similar limit
> somewhere :
>
> dg@major:~$ true | dd bs=3G count=1
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 2.1008e-05 s, 0.0 kB/s
> dg@major:~$ true | dd bs=3E count=1
> dd: memory exhausted
> dg@major:~$ true | dd bs=3Z count=1
> dd: invalid number `3Z'
>
> I can see an argument that there might want to put a better error message in, or state that the bs is dependent on memory
> size.

Thanks for the report.

dd is trying to tell you not to specify such a large buffer size.
A buffer size larger than a few megabytes is not normally useful.

That diagnostic is not helpful indeed, but it was easy to fix,
so I'll probably apply something like the following upstream.
With the new diagnostic, you can see that dd tries (and fails)
to allocate output buffers of the specified size:

    $ :|./dd bs=3EiB
    ./dd: failed to allocate an input buffer of size 3.0 EiB
    [Exit 1]
    $ :|./dd obs=3EiB
    ./dd: failed to allocate an output buffer of size 3.0 EiB
    [Exit 1]

Making dd give a better diagnostic for e.g., "bs=3G" on an i686
system might be more work than it's worth.