From owner-freebsd-current@FreeBSD.ORG Tue Apr 13 10:53:43 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 B699916A4CE; Tue, 13 Apr 2004 10:53:43 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67CF643D4C; Tue, 13 Apr 2004 10:53:43 -0700 (PDT) (envelope-from tim@kientzle.com) Received: from kientzle.com (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i3DHrh90023088; Tue, 13 Apr 2004 10:53:43 -0700 (PDT) (envelope-from tim@kientzle.com) Message-ID: <407C2924.2050503@kientzle.com> Date: Tue, 13 Apr 2004 10:53:40 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brian F. Feldman" References: <200404090121.i391LRlr096539@green.homeunix.org> In-Reply-To: <200404090121.i391LRlr096539@green.homeunix.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/tar Makefile bsdtar.1 bsdtar.c bsdtar.h bsdtar_platform.h matching.c read.c util.c write.c 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, 13 Apr 2004 17:53:43 -0000 Brian F. Feldman wrote: > > ... bsdtar is ALWAYS faster than the (multi-process) tar tfy/xfy! Well, well, well. That's a pleasant surprise. > ... it should be possible to get more speed out of bsdtar by actually pulling in > the entire size of a block ... it's silly to save a little bit of space by > using a very small "file read" buffer. For S_ISREG() use no KB instead of > 10KB by using mmap(2), maybe... The 10KB default buffer size is actually dictated by various standards that were designed for old tape drives. I didn't do that to save space. In fact, libarchive is designed to handle a wide variety of I/O strategies. Bsdtar is just a particularly conservative client at the moment, one that uses a convenience routine that just reads fixed-size blocks. This is suitable for tape I/O, but we can do better for files. Libarchive calls a client-provided routine to read each "block" of input, but puts no restrictions on the size of those blocks. (For example, I've tested libarchive with a routine that always returns a single byte. Slow, but it works.) It is perfectly reasonable for the client routine to mmap() the entire file and return the whole thing as a single block. Libarchive is a bit more restrictive on write than on read; it always writes fixed-size blocks, but you can at least set the block size (and set whether or not the last block is padded). In particular, you could set 100k blocks and pad out to the next multiple of 10k, which should be considerably more efficient for the S_ISREG() case. Tim Kientzle