From owner-freebsd-current  Sun Mar  5 22:45:41 1995
Return-Path: current-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA24302 for current-outgoing; Sun, 5 Mar 1995 22:45:41 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA24295; Sun, 5 Mar 1995 22:45:25 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA15475; Mon, 6 Mar 1995 16:41:27 +1000
Date: Mon, 6 Mar 1995 16:41:27 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199503060641.QAA15475@godzilla.zeta.org.au>
To: current@freefall.cdrom.com, jkh@FreeBSD.org
Subject: Re: "Sparse" files?
Sender: current-owner@FreeBSD.org
Precedence: bulk

>Do we have any support for the likes of Linux's sparse files?  Patrick
>here says it saves around 25% for executables alone when run-length
>compression is done for zero'd blocks.

ffs certainly supports holes in regular files.  Gnu cp preserves holes
in regular files and creates them if possible, at least on POSIX file
systems for which stat() returns suitable non-POSIX info (st_blocks
and/or st_blksize).  Our cp neither creates them nor preserves them.
It might be difficult to support them and still use mmap().

The usual ffs block size is 8K, while the usual linux block size is 1K,
so the chance of finding a zero block to compress is much lower.

Bruce