From owner-freebsd-hackers Mon May 1 10:36:22 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA01333 for hackers-outgoing; Mon, 1 May 1995 10:36:22 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA01327 for ; Mon, 1 May 1995 10:36:18 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA07524; Mon, 1 May 95 11:29:46 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505011729.AA07524@cs.weber.edu> Subject: Re: Compress dumps? To: obrien@leonardo.net (Mike O'Brien) Date: Mon, 1 May 95 11:29:46 MDT Cc: hackers@FreeBSD.org In-Reply-To: <199505010612.XAA00432@caern.protocorp.com> from "Mike O'Brien" at Apr 30, 95 11:12:46 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > Just a thought, but has anyone given any thought to running the > "dump" data stream through 'gzip' on its way to the tape, so that we > don't have to buy quite as many QIC-80 tapes? Sort of like the regular > CMS 'tape' program does under DOS/Windows? I always want to cry when someone suggests stream compression on dump formats. Without the compression, you can recover if your cat (or girlfriend or boyfriend or significant whatever) eats a hole in the tape (if if you have mylar-moths ...you get the idea). With stream compression, you get to lose all of the data following the munged area because you require compression state prior to the area being decompressed to correctly decompress. One possible fix is to go to a block compression scheme or a file compression scheme as the tapes are written. In that case, the maximum loss is when the cat senses a boundry to chew on and you lose the end of one and the start of another... so you lose two blocks-or-files depending on the compression scheme. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.