From owner-freebsd-hackers@FreeBSD.ORG  Wed Aug  2 14:54:26 2006
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
X-Original-To: freebsd-hackers@freebsd.org
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 11D2F16A4DD;
	Wed,  2 Aug 2006 14:54:26 +0000 (UTC)
	(envelope-from bakul@bitblocks.com)
Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7819D43D72;
	Wed,  2 Aug 2006 14:54:22 +0000 (GMT)
	(envelope-from bakul@bitblocks.com)
Received: from bitblocks.com (localhost [127.0.0.1])
	by mail.bitblocks.com (Postfix) with ESMTP id 11A9C2948D;
	Wed,  2 Aug 2006 07:54:22 -0700 (PDT)
To: Peter Jeremy <peterjeremy@optushome.com.au>
In-reply-to: Your message of "Wed, 02 Aug 2006 17:33:40 +1000."
	<20060802073340.GA713@turion.vk2pj.dyndns.org> 
Date: Wed, 02 Aug 2006 07:54:22 -0700
From: Bakul Shah <bakul@bitblocks.com>
Message-Id: <20060802145422.11A9C2948D@mail.bitblocks.com>
Cc: freebsd-hackers@freebsd.org, Tim Kientzle <kientzle@freebsd.org>
Subject: Re: [PATCH] adding two new options to 'cp' 
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2006 14:54:26 -0000

> As a general comment (not addressed to Tim):  There _is_ a downside
> to sparsifying files.  If you take a sparse file and start filling
> in the holes, the net result will be very badly fragmented and hence
> have very poor sequential I/O performance.  If you're never going to
> update a file then making it sparse makes sense, if you will be
> updating it, you will get better performance by making it non-sparse.

Except for database tables how common is this?  And for such
files how important is the sequntial I/O performance?  For
database tables perhaps there is a size range where not
making them sparse helps but for really large tables you
wouldn't want to fill in the holes.  I suspect that making
not writing zeroes the default would actually help overall
performance.