From owner-freebsd-hackers Tue May 5 23:19:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA19937 for freebsd-hackers-outgoing; Tue, 5 May 1998 23:19:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA19913 for ; Tue, 5 May 1998 23:19:24 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yWx8P-0006MO-00; Tue, 5 May 1998 22:52:53 -0700 Date: Tue, 5 May 1998 22:52:51 -0700 (PDT) From: Tom To: Terry Lambert cc: beng@lcs.mit.edu, dec@phoenix.its.rpi.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE In-Reply-To: <199805060233.TAA26505@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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