Date: Wed, 07 Apr 2004 10:30:55 -0700 From: Tim Kientzle <tim@kientzle.com> To: "Brian F. Feldman" <green@FreeBSD.org> 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 Message-ID: <40743ACF.9090701@kientzle.com> In-Reply-To: <200404070820.i378KDoP066199@green.homeunix.org> References: <200404070820.i378KDoP066199@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian F. Feldman wrote: > Tim Kientzle <tim@kientzle.com> wrote: > >>Ruslan Ermilov wrote: >> >>>On Mon, Apr 05, 2004 at 02:32:18PM -0700, Tim Kientzle wrote: >>> >>> >>>>kientzle 2004/04/05 14:32:18 PDT >>>> >>>> FreeBSD src repository >>>> >>>> Added files: >>>> usr.bin/tar Makefile bsdtar.1 bsdtar.c bsdtar.h >>>> bsdtar_platform.h matching.c read.c >>>> util.c write.c >>>> Log: >>>> Initial commit for bsdtar. >>>> > > What if you do compression as a worker thread? I don't know how performance > compares, but proof of concept is: > <http://green.homeunix.org/~green/libarchive_bz2thread.patch>; I'll take a look at your code, but I'm reluctant to spawn threads within a library for a number of reasons, ranging from client expectations (if you invoke the client-provided I/O routines within a separate thread, then you can encounter a situation where a non-threaded program might have to lock it's private data) to the potential for conflicts between threaded/non-threaded libc implementations. Since the client can provide it's own I/O routines, performance-sensitive clients could implement compression/decompression within their own code and play any games they like. (I've considered implementing async I/O in bsdtar, for instance.) But I think the current approach taken by libarchive is the right one for general-use library code. In the particular case of bzip2 compression, I suspect that bigger gains could be had by increasing the compression buffers to around 1meg and invoking the compression routines less often. I have a feeling that there's a lot of overhead in just entering the bzip2 compression functions. > Good job on bsdtar and libarchive! I'm curious if you're trying to make tar > -t output in the same long format as GNU tar -- it appears to have link > count, but not the year part of the date. No. I'm actually trying to follow "ls -l" format. This was suggested by a note in the POSIX standard that recommends this format for the "pax" utility (which has replaced "tar" in newer versions of the POSIX standards). I looked at a number of tar implementations to see if there was any significant consistency, but didn't find any. Following "ls -l" seems like the right approach. Tim Kientzle
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40743ACF.9090701>