From owner-freebsd-hackers Mon May 4 21:35:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA19994 for freebsd-hackers-outgoing; Mon, 4 May 1998 21:35:52 -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 VAA19969 for ; Mon, 4 May 1998 21:35:44 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yWZ2h-0005GE-00; Mon, 4 May 1998 21:09:23 -0700 Date: Mon, 4 May 1998 21:09:15 -0700 (PDT) From: Tom To: Benjamin Greenwald cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE In-Reply-To: <199805042222.SAA08117@shangri-la.lcs.mit.edu> 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 Mon, 4 May 1998, Benjamin Greenwald wrote: > > > It's been fairly well proven that dump/restore is by far the most accurate > way > > > of backing up one's filesystems. > > > > Really? Since dump/restore requires direct knowledge of filesystem > > internals, it should probably be dropped for being a gross layering > > violation alone. Assuming it can even capture a consistant view of an > > active filesystem (I doubt it myself). dump/restore's idea of raw > > filesystem access was a mistake. > > > > Dump/restore gains it's accuracy precisely because it breaks the abstraction. > UFS filesystems contain UFS specific info which utilities like tar don't > capture, not to mention dump has better accuracy on very wierd files. This > isn't a slight against tar... tar gains a great deal from being filesystem > indifferent including speed (as you mentioned) and portability. 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. > There is simply no way to totally capture UFS without breaking the > abstraction... if you're going to assume the filesystem type why not look at > the raw disk and so you really know what's going on? > > An obvious and simple example: imagine tar'ing up some files flaged uchg. How > do you propose we make sure the restored files are also flaged uchg without > assuming we are using UFS? uchg is just another file attribute, and could be supported on non-UFS filesystems. An archiver should store all file attributes, and restore them as possible. 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! - You need to be read permissions to the raw filesystem to run dump. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message