Subject: Re: GNU tar goodbye?
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 10/11/2002 17:32:36
[ On Friday, October 11, 2002 at 13:31:27 (-0700), Bill Studenmund wrote: ]
> Subject: Re: GNU tar goodbye?
> Your tone above does little to encourage discourse. Your tone indicates
> that you have decided '--fast-read' is not important, and that that's
I didn't think it was necessary to go into any analysis of why
'--fast-read' was not important -- I thought it was quite self obvious,
and even if not then it would be should anyone take a moment to read
about what it does in the manual page.
> It doesn't matter why people want it, they want it. We have it now. To
> switch tar -> pax-as-tar w/o --fast-read will be a step backwards for a
> number of our users.
None have spoken up about this particular "feature" yet. Who are these
users? How many of them are there? How many of them _really_ care
about this particular feature? How many would notice if it were a no-op?
> Also, we're talking about a time optimization. By its definition, things
> will work w/o it, just slower.
Exactly my point.
> Arguing we don't need it because things
> work w/o it misses the point.
These kinds of optimisations are things that can be (re)added at any
time in the future. They're really not necessary to get basic
functionality out the door.
> One of the main reasons we want it is for supporting binary packages. One
> of the first things we do is grab the +CONTENTS file. There will be only
> one, and it usually is at the front of the file. So it's REALLY SILLY to
> read the whole file to find out that there isn't another copy of the file
> we knew there was only one copy of.
I offered patches to make pkg_* mostly work with the native 'pax'
interface quite a long time ago. I think the PR is still in the
original open state with only a mostly un-related comment attached to it
Yes those patches basically ignore the optimisations that would be
possible with support for a "stop when we've found the first instance of
all the files we're looking for" feature in pax, but like I say those
kinds of things can easily come along later.
> So no --fast-read == about 200x system time increase, and a LOT of user
Sure but it's not really a "LOT of user time" because it's time that's
not repeated very often for any given user. I use binary packages
exclusively for some systems I support and I haven't noticed a lack of
'--fast-read' wasting any of my time in any ongoing way.
(well, if someone uses an un-optimised pax or tar, as I do, in an
environment where PKG_PATH is pointed at a remote FTP URL, as I do on
occasion, and they happen to run pkg_info in certain ways, then even
worse performance problems in pkg_info itself are almost immediately
made much more readily apparent.... :-)
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>