From owner-freebsd-hackers Tue Jun 17 00:35:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA00331 for hackers-outgoing; Tue, 17 Jun 1997 00:35:48 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA00322 for ; Tue, 17 Jun 1997 00:35:44 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA00528 for freebsd-hackers@FreeBSD.ORG; Tue, 17 Jun 1997 09:35:37 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id QAA07792; Sun, 15 Jun 1997 16:02:52 +0200 (MET DST) Message-ID: <19970615160250.HK59536@uriah.heep.sax.de> Date: Sun, 15 Jun 1997 16:02:50 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: dump/restore with compression References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Brandon Gillespie on Jun 12, 1997 13:40:51 -0600 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Brandon Gillespie wrote: > Is there plans to integrate a compression option into dump and restore? > Does anybody USE dump/restore anymore? I've been using the Digital Unix > equivalent 'vdump' and 'vrestore' for a while now, and it has a lot more > capability than the older dump/restore (such as compression 8) ``a lot more'' is a bit of an overstatement. Apart from it being created to handle AdvFS (and thus AdvFS filesets), it has just -D (for backing up subdirectories, as opposed to entire filesystems or filesets), and -C, that are real advantages. What i didn't like is that they broke compatibility. vdump's output is incompatible with dump's. That's something they shouldn't have broken without reason. dump is compatible across machines, even if it doesn't look so at the first glance. Adding compression shouldn't be too hard. You gotta add a new flag, link libz to the binary (which will unfortunately bloat it), and you should probably store the filename inside the archive with a `.gz' appended. This way, an older restore that doesn't understand the compression flag will just restore a gzip'ed file, while a newer restore will decode the flag, and knows that it can strip the `.gz' after decompressing the file. For files that are already compressed, you simply omit the flag. It requires somebody doing it. :-) Even given Terry's vehemental vote for a block compression, i'd rather like to see it as outlined above, since it's probably the most flexible variant. Of course, i personally wouldn't use it much, but rely on the hardware compression of my tape drive. ;) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)