Date: Wed, 10 Oct 2012 22:46:11 +0200 (CEST) From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> To: Kurt Lidl <lidl@pix.net> Cc: Brandon Falk <bfalk_bsd@brandonfa.lk>, freebsd-hackers@freebsd.org Subject: Re: SMP Version of tar Message-ID: <alpine.BSF.2.00.1210102243440.2176@wojtek.tensor.gdynia.pl> In-Reply-To: <20121010143314.GA8402@pix.net> References: <5069C9FC.6020400@brandonfa.lk> <alpine.BSF.2.00.1210071859430.15957@wojtek.tensor.gdynia.pl> <324B736D-8961-4E44-A212-2ECF3E60F2A0@kientzle.com> <alpine.BSF.2.00.1210080838170.3664@wojtek.tensor.gdynia.pl> <20121008083814.GA5830@straylight.m.ringlet.net> <alpine.BSF.2.00.1210081219300.4673@wojtek.tensor.gdynia.pl> <15DBA1A9-A4B6-4F7D-A9DC-3412C4BE3517@kientzle.com> <20121010143314.GA8402@pix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Tim is correct in that gzip datastream allows for concatenation of > compressed blocks of data, so you might break the input stream into > a bunch of blocks [A, B, C, etc], and then can append those together > into [A.gz, B.gz, C.gz, etc], and when uncompressed, you will get > the original input stream. > I think that Wojciech's point is that the compressed data stream for > for the single datastream is different than the compressed data > stream of [A.gz, B.gz, C.gz, etc]. Both will decompress to the same > thing, but the intermediate compressed representation will be different. So - after your response it is clear that parallel generated tar.gz will be different and have slightly (can be ignored) worse compression, and WILL be compatible with standard gzip as it can decompress from multiple streams which i wasn't aware of. That's good. at the same time parallel tar will go back to single thread when unpacking standard .tar.gz - not a big deal, as gzip decompression is untrafast and I/O is usually a limit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1210102243440.2176>