Date: Tue, 5 May 1998 22:52:51 -0700 (PDT) From: Tom <tom@sdf.com> To: Terry Lambert <tlambert@primenet.com> Cc: beng@lcs.mit.edu, dec@phoenix.its.rpi.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE Message-ID: <Pine.BSF.3.95q.980505223633.24411A-100000@misery.sdf.com> In-Reply-To: <199805060233.TAA26505@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 May 1998, Terry Lambert wrote:
> > dump/restore does not work on my 32GB filesystem. Why? Possibly a 4+GB
> > bug, though somone has speculated that it is sparse file problem. What
> > happens? dump generates a corrupted archive (bug), and restore detects
> > the corruption and crashes anyway (another bug). There has been
> > an outstanding PR on this for a long time.
>
> There is no "4G problem". If there is a problem based on type size,
> it will occur at 2G + 1, *not* 4G.
A "long" or an "unsigned long" used as a byte offset. It is splitting
hairs.
...
> Now you are claiming the problem occurs in dump instead of restore.
No. It is dump/restore.
> If the problem has anything to do with sparse files (which it doesn't),
> you will be able to repeat it by creating a file, writing some small
> number of blocks up front, and then seeking out to:
>
> off_t off = 1 << 34;
>
> And writing some more blocks, then dumping the FS containing the file.
>
> You could fit this file on a floppy disk, since it's sparse, and make
> the test case teeny.
>
> Having run this experiment the other night with my QIC SCSI 2525
> drive, I can tell you that the problem is not in dump or restore,
> unless it's a byte/block offfset problem.
>
> If you are seeing a byte/block offset problem, it's not going to be
> occurring where ou are saying you are seeing the problem ("4G"), it's
> going to occur at one of the boundry conditions I identified, above.
>
>
> If you are seeing a problem where you said you are seeing the problem,
> then it is the driver/controller/tape drive/tape that is causing it.
What? Was something about my message unclear? restore dies with a
"hole in map". You can also search the PR database for that phrase to
find an indentical report to the one I filed.
The tape and drive are ok. I tar'ed the entire filesystem up, newfs the
filesystem, and untar the tape, and it works great (which I have done as a
test.
>
> What version of FreeBSD are you running?
2.2.6-STABLE
> What is the controller for the tape drive?
2940UW
> Which driver is responsible for that controller?
ahc
> What exact model of tape drive are you using?
Quantum DLT 4000
> What exact brand of tapes are you using?
Quantum DLT IV
> What is the controller for the disk showing the problem?
EIDE
> What driver is responsible for that controller?
wd
> What exact model of disk drive are you using?
Maxtor DiamondMax 8.4GB
> Are you overclocking your processor?
No.
You know what a much better test would be? I can do a dump, read the
first hundred megs or so with dd into a file, and send it to you. Since
"restore -t" reports the "hole in map" within seconds, it obviously hasn't
read very far into the tape yet, so doing a restore from a disk file
should have the same result.
>
> Terry Lambert
> terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
Tom
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.980505223633.24411A-100000>