From owner-freebsd-current Sun Mar 5 23:12:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA24600 for current-outgoing; Sun, 5 Mar 1995 23:12:57 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA24593; Sun, 5 Mar 1995 23:12:56 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Brian Tao cc: "Jordan K. Hubbard" , current@freefall.cdrom.com Subject: Re: "Sparse" files? In-reply-to: Your message of "Mon, 06 Mar 95 14:53:14 +0800." Date: Sun, 05 Mar 1995 23:12:55 -0800 Message-ID: <24592.794473975@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I thought ffs could already compress sparse files? Apple II ProDOS > does this, but it isn't strictly "compression". I think it simply > doesn't bother to allocate disk blocks for any that are completed filled > with null bytes. There's no performance hit, and this is on floppy-bound > 1-MHz //e's and //c's... :) I don't think it does it on-the-fly, no. Bruce pretty much clinched it when he pointed out that GNU cp, which linux uses by default, automatically creates the holes and so their executables "compress" as they're installed (or moved elsewhere). GNU tar also has support for this and they probably leave the flag on (--sparse) by default. But as Bruce also points out, our block size of 8K also makes this kind of compression scheme much less likely to be effective. Jordan