Date: Thu, 7 May 1998 23:27:39 -0700 (PDT) From: Tom <tom@sdf.com> To: Terry Lambert <tlambert@primenet.com> Cc: beng@lcs.mit.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE Message-ID: <Pine.BSF.3.95q.980507230302.3188E-100000@misery.sdf.com> In-Reply-To: <199805072222.PAA13813@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 May 1998, Terry Lambert wrote: > > > > That is bizare. So it prints a "y/n" prompt and calls the panic > > function anyhow? > > Look at the code. > > You could argue that this was a cosmetic bug. I've been arguing that since day 1. > > > One possible reason for this problem *could* ge your limits on the > > > account doing the restore (see login.conf). > > > > I run restore as root. > > Root is limited by login.conf, just like everyone else. No, root is not limited by login.conf. Also, "time -l" shows resource usage for restore. A "maximum resident set size" of 1264 isn't exactly hard for even a non-root user to cover. > > Media is good. Dump to disk file does same thing. I've proved that the > > tape media and tape drive are not a factor. > > OK. Now we need proof that it isn't the raw disk device, the EIDE > controller, the EIDE drive, the cable being too long, etc.. It is not the cables. Standard 18 inch cables. > If you can do that, we still haven't localized it to whether it's > dump writing bad data or restore thinking there's bad data when there > isn't. Except that I could send over a copy of the first few megs of a dump archive that doesn't work, and you could prove whether the archive is valid or not. On the other hand, assume that when dump reads the disk, it gets garbage. Dump takes the garbage and writes an archive. Why does restore crash reading the archive? Isn't restore just dump in reverse? Any archive written by dump should be restorable by restore. ... > Or a fail under heavy access bug. Unlikely that dump produce enough load. The drives can do about 5MB/s sustained filesystem performance. A DLT that can do about 1500KB/s (as reported by dump), isn't going to be stressing it that much. ... > This still won't eliminate some possible non-sequential access bugs > that could be introduced either by the driver, the disk cache, or the > VM system. I guess there is no point arguing "the simplest explanation is always the best." > 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.980507230302.3188E-100000>