From owner-freebsd-hackers Tue May 5 01:17:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA21064 for freebsd-hackers-outgoing; Tue, 5 May 1998 01:17:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA20979 for ; Tue, 5 May 1998 01:17:02 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id BAA22102; Tue, 5 May 1998 01:16:59 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd022089; Tue May 5 01:16:50 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id BAA19281; Tue, 5 May 1998 01:16:48 -0700 (MST) From: Terry Lambert Message-Id: <199805050816.BAA19281@usr02.primenet.com> Subject: Re: Network problem with 2.2.6-STABLE To: tom@sdf.com (Tom) Date: Tue, 5 May 1998 08:16:48 +0000 (GMT) Cc: beng@lcs.mit.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Tom" at May 4, 98 09:09:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Perhaps, but dump/restore is broken for large filesystems. Perhaps one > of the dump/restore advocates should fix it before a new user is swayed by > the rhetoric into using dump/restore, only to watch restore core dump on > large dumps. Be happy to. Where is you real bug report that details the problem, instead of just stating that there is one? So far, all I have seen is a bit of FUD with no real basis below 1TB -- far out of the range claimed for the problem (4GB, which doesn't make sense anyway, since indirect blocks are negated, so at best you could claim 2GB because of the sign, IFF dump operated on byte offsets instead of block offsets, which it doesn't). > Other problems with dump/restore: > > - Tape format is specific to dump, and can't be read anywhere else. The > current large filesystem bug could be a data structure problem, which in > order to fix will break compatibility with old tapes! No. You write a different header that indicates that you are going to be using 63 instead of 31 bit offsets. The different header is only written in the case that the FS is large enough to trigger the alleged problem. > - You need to be read permissions to the raw filesystem to run dump. This is not a bug, it is a feature. If I can dump an FS without read permiision, I can take the tape to my own box and violate system security by reading the tape in there, where I have root privs. PS: how did you get write access to one raw device (the tape drive) an find yourself unable to get read access to a different raw device? PPS: sudo. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message