From owner-freebsd-current Mon Mar 6 10:08:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA13529 for current-outgoing; Mon, 6 Mar 1995 10:08:48 -0800 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 KAA13523 for ; Mon, 6 Mar 1995 10:08:47 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA18642; Mon, 6 Mar 95 11:02:20 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503061802.AA18642@cs.weber.edu> Subject: Re: "Sparse" files? To: jkh@FreeBSD.org (Jordan K. Hubbard) Date: Mon, 6 Mar 95 11:02:20 MST Cc: current@freefall.cdrom.com In-Reply-To: <199503060557.VAA00476@time.cdrom.com> from "Jordan K. Hubbard" at Mar 5, 95 09:57:18 pm X-Mailer: ELM [version 2.4dev PL52] 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. This almost requires dual-staging in the FS, such that a block read off of disk can become more than one block in core. This is effectively what you'd want to do blobk-based deterministic compression, for instance adding doublespace support to the DOSFS. I suspect a lot of the speed pickup is that this would effectively cause a read-ahead of however many blocks a single block decompresses to minus one (which is what make this not act as a performance loss in practice). Effective read-ahead for binaries would probably unmask this as a false win. You'd be left with some space savings at a rather steep access penalty. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.