From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 13:13:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C738316A4CE for ; Sat, 24 Jul 2004 13:13:55 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 982CC43D5D for ; Sat, 24 Jul 2004 13:13:55 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i6ODDk90052449; Sat, 24 Jul 2004 06:13:46 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4102608A.1030805@freebsd.org> Date: Sat, 24 Jul 2004 06:13:46 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Lang References: <40F963D8.6010201@freebsd.org> <20040719060730.GA87697@nagual.pp.ru> <20040720081051.GB3001@cirb503493.alcatel.com.au> <20040721151427.GC54664@atrbg11.informatik.tu-muenchen.de> In-Reply-To: <20040721151427.GC54664@atrbg11.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: Jan Grant cc: Stefan Bethke cc: Peter Jeremy Subject: Re: NEW TAR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 13:13:55 -0000 Daniel Lang wrote: > > I assume, that for any consumer it is totally transparent if > possibly existing chunks of 0-bytes are actually blocks full of > zeroes or just non-allocated blocks, correct? For most practical users, it is totally transparent, and in practice, "sparse file storage" in tar files is purely a compression technique. However, there are unusual cases both directions that need to be considered: If you don't restore a sparse file as a sparse file, you risk running out of disk space. If you restore a non-sparse file as a sparse file, then the file will be slower to write to (because the OS has to allocate space and because the file storage will be more fragmented). Also, there will be applications that do not handle "disk full" errors when they try to write to the middle of an existing file. Tim