I think I may have found a bug in dd or else something is wrong with
christoph.scheeder at scheeder.de
Fri Sep 8 00:03:15 PDT 2000
not dd's fault. You are banging into the 2GB-Filesizelimit of linux.
simple calculation: 65536 Blocks * 32k per block =2GB filesize.
you'll never get the complete image back to the disk on the linux-box,
as it is too large for the filesystem.
you'll have to pipe the data directly into the restore-programm or
to the remote-client.
Jeff Silverman schrieb:
> Hi. I think I have found a bug in dd, but before I go make a fool of
> myself in front of FSF, I'd like to run it past you and see if you
> I am trying to restore a file using amrestore and I am having mucho
> trouble with the pipe breaking, so I decided to bypass amanda and do the
> restoration by hand.
> spinoza!root 528# dd if=/dev/nst0 bs=32k skip=1 of=dump_image_7
> dd: dump_image_7: File too large
> 65536+0 records in
> 65535+0 records out
> spinoza!root 529# which dd
> spinoza!root 530# dd --version
> dd (GNU fileutils) 4.0
> I am not sure I believe this, but there is the distinct possibility that
> there is a bug in dd, that it can't handle more than 64K records. That
> strains my credibility, surely I am doing something basic that's wrong.
> This is gnu dd version 4 running on Linux 2.2.14-5 (Redhat 6.1). The
> machine being backed up is a PC running SunOS 5.6
> I think the user's data is on the tape daily-008, file #9, but I just
> can't get at it. Any advice?
> Jeff Silverman, sysadmin for the Research Computing Systems (RCS)
> University of Washington, School of Engineering, Electrical Engineering Dept.
> Box 352500, Seattle, WA, 98125-2500 FAX: (206) 221-5264 Phone (206) 543-9378
> jeffs at rcs.ee.washington.edu http://rcs.ee.washington.edu/~jeffs
More information about the Linux