From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 10 19:59:59 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CF6616A417 for ; Tue, 10 Oct 2006 19:59:59 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 09DC043D5F for ; Tue, 10 Oct 2006 19:59:38 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 17941 invoked by uid 1001); 10 Oct 2006 19:59:47 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Tue, 10 Oct 2006 15:59:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17707.64434.913943.549852@bhuda.mired.org> Date: Tue, 10 Oct 2006 15:59:46 -0400 To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <200610101727.k9AHRrYo039774@lurza.secnetix.de> References: <200610101727.k9AHRrYo039774@lurza.secnetix.de> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: Mike Meyer X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) Cc: Subject: Re: "tar -c|gzip" faster than "tar -cz"?!? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2006 19:59:59 -0000 In <200610101727.k9AHRrYo039774@lurza.secnetix.de>, Oliver Fromme typed: > Is that a known problem? Is someone working on it? Not necessarily a known problem, but not a surprise. I'm not sure about the size issue - it's not clear what compression level it's running at. The real time difference is expected. tar uses libarchive, which does the compression in the process. So while piping tar's output to gzip will let gzip compress data while tar is waiting on disk I/O, having tar compress things for you means that doesn't happen. Fixing that is a non-trivial task. Since they use different code - with different licenses - some difference is expected. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.