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

[Linda Walsh]

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.

linda



Pádraig Brady wrote:

> Linda Walsh wrote:
>  
>
> > Sometimes I would like "dd" to copy the contents of
> > "Random-Block-Object-A"
> > 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
> > hallucinating?
> >    
>
> I think you are hallucinating. Put an strace before your dd command to
> confirm.
> 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"
> > behavior?
> >
> > 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`:
> http://www.pixelbeat.org/scripts/truncate
>
> Pádraig.
>