From owner-freebsd-hackers Tue May 5 18:43:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29116 for freebsd-hackers-outgoing; Tue, 5 May 1998 18:43:20 -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 SAA29057 for ; Tue, 5 May 1998 18:43:01 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yWsoq-0006BS-00; Tue, 5 May 1998 18:16:24 -0700 Date: Tue, 5 May 1998 18:16:22 -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: <199805060128.SAA21183@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: > > > 1) You are not supposed to use it on mounted FS's. > > > > Really? That isn't in the manual. It also makes it useless for > > 24x7 servers. > > Why not? Unmount a mirrored drive in a mirror array, and back it up > offline. Not possible in FreeBSD. Even where it is possible, re-syncing the disk when it is brought back into the mirror can be a real problem. > In general, the FS should be quiescent, at the very least. > > Most people run dump/restore in single user mode. ...making it a useless backup tool, but an acceptable duplication/replication tool. > > > Meanwhile, break you FS's up; your backups will take less time, too. > > > > 4GB filesystems are rather limiting. It places a large burden on the > > administrator to constantly balance storage needs. No thanks. > > I don't know where you keep getting 4G. 2^32 * 512 = 1TB. 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. While browsing the PR database, I found that dump/restore does not always save/restore the new 4.4 attributes. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message