From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 21:14:09 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 2D43716A4CE for ; Tue, 20 Jul 2004 21:14:09 +0000 (GMT) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4551A43D45 for ; Tue, 20 Jul 2004 21:14:07 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.12.11/8.11.1) with ESMTP id i6KLE083067499; Tue, 20 Jul 2004 23:14:01 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <20040720081051.GB3001@cirb503493.alcatel.com.au> References: <40F963D8.6010201@freebsd.org> <20040719060730.GA87697@nagual.pp.ru> <40FC9FC2.8050400@kientzle.com> <20040720081051.GB3001@cirb503493.alcatel.com.au> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Tue, 20 Jul 2004 23:14:00 +0200 To: Peter Jeremy X-Mailer: Apple Mail (2.618) 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: Tue, 20 Jul 2004 21:14:09 -0000 Am 20.07.2004 um 10:10 schrieb Peter Jeremy: > Actually, it's not possible to accurately determine the holes in a > file by reading it - you can't differentiate between a hole and a > allocated block of zeroes. What you need is a (new) syscall that > invokes a new VOP_... and returns a bitmap of allocated blocks. This > would be non-trival unfortunately. This one point that has been made a number of times in the past, and one I don't understand: There are no sparse files as far as the userland is concerned; it's an optimization that remains invisible, apart from space and/or performance savings. For the extraction process, it should be sufficient to seek over any extended range of zeros. When packaging files that might have holes in them, it'll certainly be nice if there was a way to skip reading all those zeros in, but that's just an optimization. The way you describe it (and others have before), it sounds like the holes were an attribute of the file that should be preserved by tar (or any other archiver); I believe it's not. Preserving them in the way your post can be read is problematic: what if the block/allocation/cluster/fragment size of the extraction target differs from the source? How far would you need to acertain compatible allocation semantics between both filesystems? Since this has come up multiple times in the past, I feel I'm missing some important detail, and I'd appreciate if someone would enlighten me. Stefan -- Stefan Bethke Fon +49 170 346 0140