From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 20:31:07 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 4A35216A4CE; Wed, 21 Jul 2004 20:31:07 +0000 (GMT) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA87143D41; Wed, 21 Jul 2004 20:31:06 +0000 (GMT) (envelope-from langd@informatik.tu-muenchen.de) Date: Wed, 21 Jul 2004 22:31:05 +0200 From: Daniel Lang To: Brooks Davis , harti@freebsd.org, Garrett Wollman Message-ID: <20040721203105.GA55687@atrbg11.informatik.tu-muenchen.de> References: <20040721151427.GC54664@atrbg11.informatik.tu-muenchen.de> <200407211622.i6LGMZrm040478@khavrinen.lcs.mit.edu> <40F963D8.6010201@freebsd.org> <20040719060730.GA87697@nagual.pp.ru> <20040720081051.GB3001@cirb503493.alcatel.com.au> <20040721151427.GC54664@atrbg11.informatik.tu-muenchen.de> <20040721162706.GA12760@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407211622.i6LGMZrm040478@khavrinen.lcs.mit.edu> <20040721162706.GA12760@Odin.AC.HMC.Edu> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r+++ y+ User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at informatik.tu-muenchen.de cc: current@freebsd.org 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: Wed, 21 Jul 2004 20:31:07 -0000 Hi, Brooks Davis wrote on Wed, Jul 21, 2004 at 09:27:06AM -0700: [..] > Since sparse files over commit the disk, they should only be created > deliberatly. Otherwise you can easily get in trouble if you try to use > reserved space later since it won't actually be reserved. Consider the > case of a file system image created with "dd if=/dev/zero ...; newfw > ...". If your archiver decides to be "smart" and restore a copy of that > file sparce and then you use up the availble blocks on your disk you're > going to be in a world of hurt. I wouldn't be suprised it that resulted > in a panic. [Garret writes:] > You've never run out of disk space as a result of a sparse file > becoming non-sparse? That was not my point. I agree, that it should be done deliberately. There should be a non-default command-line switch to enable sparse files or not (as it is common practice now anyway). But if someone chooses to use sparse files upon archive extraction (I believe this is the more important part), it does not matter how the original file layout was in terms of blocks of allocated zeroes and unallocated blocks. To Harti: I admit I don't know for sure, but to my understanding the handling of the sparse file is done in the filesystem layer and not in the application, right? Then all possible performance benefit on reading a sparse file should be gained anyway. Regardless if the application (the archiver) knows about the locations of the gaps or not.... Best regards, Daniel -- IRCnet: Mr-Spock - All your .sigs are belong to us - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/