Date: Thu, 22 Jul 2004 19:16:22 +1000 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Andrey Chernov <ache@nagual.pp.ru>, current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: NEW TAR Message-ID: <20040722091622.GG3001@cirb503493.alcatel.com.au> In-Reply-To: <20040722071929.GA13591@nagual.pp.ru> References: <40F963D8.6010201@freebsd.org> <20040719060730.GA87697@nagual.pp.ru> <40FC9FC2.8050400@kientzle.com> <20040722071929.GA13591@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2004-Jul-22 11:19:29 +0400, Andrey Chernov wrote: >On Mon, Jul 19, 2004 at 09:29:54PM -0700, Tim Kientzle wrote: >> but they're not gtar-compatible. (The gtar >> approach has a number of drawbacks. The primary >> one being that on many systems it requires reading >> the entire file twice, once to find holes and again >> to actually archive the file. It is possible to >> do both in one pass if you store the sparse file >> data in a different fashion.) > >I can't imagine the case when 2 passes are needed. Even if you have normal >file in the archive and specify -S only when extracting (it should work as >expected), only 1 pass is needed. Just stop on first '\0' and count them >until they finished, then do lseek (real case will be a bit harder to >implement because of block boundaries). I thought gnutar implemented sparse files by writing a bitmap of used blocks vs holes followed by the actual data. This needs 1 pass to calculate the bitmap and a second pass to write the data. You probably don't want to unnecessarily convert holes to data in your archive. Some Un*x systems generate a core dump by writing the process memory map to a file - holes and all - giving you a sparse file that appears to be several GB in size. Older dbm variants also tended to leave large holes in the .pag file from memory. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040722091622.GG3001>