Date: Mon, 4 May 1998 21:09:15 -0700 (PDT) From: Tom <tom@sdf.com> To: Benjamin Greenwald <beng@lcs.mit.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE Message-ID: <Pine.BSF.3.95q.980504210155.20203C-100000@misery.sdf.com> In-Reply-To: <199805042222.SAA08117@shangri-la.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.980504210155.20203C-100000>