From owner-freebsd-hackers Mon May 4 15:23:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14584 for freebsd-hackers-outgoing; Mon, 4 May 1998 15:23:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shangri-la.lcs.mit.edu (root@shangri-la.lcs.mit.edu [18.111.0.88]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA14427 for ; Mon, 4 May 1998 15:22:27 -0700 (PDT) (envelope-from beng@shangri-la.lcs.mit.edu) Received: from shangri-la.lcs.mit.edu (beng@localhost [127.0.0.1]) by shangri-la.lcs.mit.edu (8.8.7/8.8.7) with ESMTP id SAA08117 for ; Mon, 4 May 1998 18:22:23 -0400 (EDT) Message-Id: <199805042222.SAA08117@shangri-la.lcs.mit.edu> X-Mailer: exmh version 2.0.1 12/23/97 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE In-reply-to: Your message of "Sun, 03 May 1998 22:51:01 PDT." From: Benjamin Greenwald X-Sender: beng@lcs.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 May 1998 18:22:22 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG *snip* > > > > 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. 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? Abstraction is a tool... not an absolute. Just like all tools, you have to choose when it's right to use it. Don't assume any screwdriver will work until you find out whether the screws are phillips or flathead. -Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message