Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!ames!ucsd!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: Why is restore so slow? Message-ID: <10038@dog.ee.lbl.gov> Date: 19 Feb 91 11:11:16 GMT References: <50235@olivea.atc.olivetti.com> <2880@redstar.cs.qmw.ac.uk> <10003@dog.ee.lbl.gov> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 21 X-Local-Date: Tue, 19 Feb 91 03:11:16 PST In article bzs@world.std.com (Barry Shein) writes: >Anyone have any thoughts on the idea of writing a restore which >restores a standard dump thru the raw device? Funny how these things come full circle: the original `restor' scribbled directly on the raw device. Kirk threw it out when he designed the 4.2BSD Fast File System, and not just because it only wrote 4.1BSD-style file systems. It also required that you restore onto the same *size* file system. You could, of course, move the kernel FFS code into user space (or maybe find a copy of Kirk's original implementation, which lived in user space) and make restore talk to that. If you really wanted to reimplement wheels, you could make your user FFS run via RPC+XDR over the network (sockets/pipes). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov