[Top][All Lists]

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

Re: on "dd" using "seek" vs. "read" & >32-bit sizes

From: Linda Walsh
Subject: Re: on "dd" using "seek" vs. "read" & >32-bit sizes
Date: Fri, 16 Dec 2005 16:03:26 -0800
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

I'll have to recheck this with more current versions.
It wasn't that "dd" didn't copy >32-bit files, I just had
problems with specifying offsets >32bits.

At one point, I was trying to get some clue about what was going
on as I copied disk drives.  I thought to use a shell script
loop construct, copying large junks from disk A -> B, incrementing
the starting offset to "dd", allowing me to update progress of how
far along the "copy" was to the screen.

At the time I tried it (some years back), strace showed me
sequential reads and rollovers after 2 or 4G.  When I brought
up the issue, I was told it was because I was running on a
32-bit machine, and I shouldn't expect 32-bit pentium3 (and I suppose
pentium4 machines, now) to do 64 bit arithmetic, and I should
upgrade my machine to something that could handle 64 bits, and
on a 32-bit machine, 32-bit arithmetic should be good enough.

I'll try it again at some point and see if the problems I had have
been resolved.  It seemed like a philosohical difference more than
a practical difference, so I wasn't sure when it would get fixed
or how reliably such a fix would be disseminated through the
the coreutils.


Pádraig Brady wrote:

Linda Walsh wrote:
Sometimes I would like "dd" to copy the contents of
to "Random-Block-Object-B", starting from the middle of of the file.

I can specify the "seek=BLOCKS" param, but it appears that "dd" doesn't
translate this to a "seek" command but instead uses "read" to to
sequentially access the block device.  Is this the case or am I

I think you are hallucinating. Put an strace before your dd command to
seek is a pretty fundamental feature of a block device :)

If I am not hallucinating, I can see this being done by design
from a historical perspective, working with tapes or such, but I'm
not sure it makes as much sense today.  Perhaps an attempt at an lseek
on an "OS", and if that fails, then failover to the older "read"

If it is deemed necessary, maybe some flag to force old behavior?

It gets painful when copying multi-gigabyte images where one may have
already copied previous parts of an image.

Second question I had -- at times, it seems like various utils
are limited to 2G file offsets on OS's (i686-linux, i686-cygwin)
that support files >2G.  Is this "old" behavior that will (should?)
be disappearing?  I'd noticed it before in specifying counts
and such in "dd" (among others).

What platform, filesystem and version of dd are you using?
I've confirmed on my fedora core 3 & ubuntu 5.10 systems
that I can seek to 2TB with the command `truncate 2TB ext3.test`:


reply via email to

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