Date: Tue, 05 May 1998 03:55:16 -0400 From: Benjamin Greenwald <beng@lcs.mit.edu> To: Tom <tom@sdf.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: dump/restore (Was Re: Network problem with 2.2.6-STABLE) Message-ID: <199805050755.DAA28510@miris.lcs.mit.edu> In-Reply-To: Your message of "Mon, 04 May 1998 21:09:15 PDT." <Pine.BSF.3.95q.980504210155.20203C-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
*snip* > > Dump/restore gains it's accuracy precisely because it breaks the abstractio n. > > 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. This is precisely what I am advocating... > > > 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 a t > > 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. So you are saying that the archiver should be responsible for backing up every file attribute from every possible filesystem? How do you propose this be done? How do you propose the archiver even know these bits exist without knowing the underlying filesystem? > > Other problems with dump/restore: > > - Tape format is specific to dump, and can't be read anywhere else. The Dump isn't portable... it's not meant to be. It's meant to be accurate. What I've been saying all along is that if portablity is the issue, tar/pax/(insert other choice here) are absolutely the right choice. > > - You need to be read permissions to the raw filesystem to run dump. > > Tom > Tar and cousins are also absolutely the correct choice if you are just your average user (translate don't have read permission to the raw device) and only want a portion of the filesystem that you know you haven't done anything funky with. Dump isn't meant for bringing home files from the office... it's meant for admins who can't count on the contents of the filesystems to be well behaved and need assurances about the quality of the dumped image relative to the actual contents/metadata of the filesystem in the event of serious problems and/or catastrophic failure. Having done some sysadmin myself, I wouldn't trust my filesystems to tar for a second. In the event I fry every disk on my fileserver I want to know FOR SURE that no more than a day's work is going to be lost. Tar can't guanantee that... dump can... period. And if I had any partitions larger than 4GB, I'd look into the problem myself. -Ben 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?199805050755.DAA28510>