Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.wizards Subject: Re: Why is restore so slow? Message-ID: Date: 18 Feb 91 23:28:57 GMT References: <50235@olivea.atc.olivetti.com> <2880@redstar.cs.qmw.ac.uk> <10003@dog.ee.lbl.gov> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 26 In-Reply-To: torek@elf.ee.lbl.gov's message of 18 Feb 91 10:29:21 GMT We've suffered thru this slow restore problem here, so it's on my mind. Anyone have any thoughts on the idea of writing a restore which restores a standard dump thru the raw device? This would be for the first, zero level dump image (I guess, perhaps it would be easy enough to apply incrementals this way also tho they're usually less of a problem.) It would seem that would bypass the synchronous directory problem w/o too much disruption to, eg, the kernel. And one could still use good ol' restore on the same tapes if there were any doubts or problems. I like the conservative nature of this approach, your tapes and backup procedures remain unchanged, only restoral is affected. Mostly a matter of simulating the file system at user-level and deciding which block it would throw things into as they come off of tape. Thoughts? Think it would be a lot faster? -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD