GNU bug report logs -
#12626
Bug?: dd limited to <2G read size (2G-8K) on 64 bit machine?
Previous Next
Reported by: Linda Walsh <coreutils <at> tlinx.org>
Date: Fri, 12 Oct 2012 03:13:02 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#12626: Bug?: dd limited to <2G read size (2G-8K) on 64 bit machine?
which was filed against the coreutils package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 12626 <at> debbugs.gnu.org.
--
12626: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12626
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
tag 12626 notabug
stop
On 10/12/2012 07:42 AM, Paul Eggert wrote:
> On 10/11/2012 11:39 PM, Linda Walsh wrote:
>> I'm not even getting error messages if I try to do 4G @ a time
>
> That's what dd is supposed to do. It requests 4 GB,
> the kernel gives it only 2 GB, so it goes with 2 GB.
> dd has always worked that way, and POSIX requires it
> to work that way.
As my mother would say, that's a lazy man's load.
Please use a more reasonable buffer size.
Also note the iflag=fullblock option, which
will ensure the internal buffer is filled.
Then count= will refer to the number of buffers
processed, rather than the number of read()s.
Also note if you specify ibs and obs seperately,
then you will get writes of the size you requested at least.
But be careful with using this behavior in conjunction
with count=, as that will limit the number of read()s.
cheers,
Pádraig.
[Message part 3 (message/rfc822, inline)]
I'm running on a 64-bit version of openSuse 12.1 with a 3.6 vanilla kernel.
I find that if I try to use a read size of > (2G-8K), I get partial read
errors.
Ishtar:> free
total used free shared buffers cached
Mem: 49487868 31923108 17564760 0 1077920 18871456
-/+ buffers/cache: 11973732 37514136
Swap: 8393924 18308 8375616
---
Should have plenty of memory. I do have huge page support turned on.
ulimit doesn't look to be the problem (tried as root)
core file size (blocks, -c) 100000
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 386074
max locked memory (kbytes, -l) 512
max memory size (kbytes, -m) 42064712
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 386074
virtual memory (kbytes, -v) 46305440
file locks (-x) unlimited
This bug report was last modified 12 years and 224 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.