On Jan 22, 2008 2:22 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote: > The zap proposal was pretty solid as I recall (although I am partial > to tar as an archive format...). I hope we can get to coding > file-package support in the next preview release interval, or perhaps > the one after that...
I would like to see something different than tar, because... - The logical thing to do with a tar file is to compress it. If you are working on a system with slow single thread performance, processing compressed tar (or cpio) archives is extremely slow. I suspect the Indiana world doesn't see this so much because the system requirements are such that a reasonably modern x86 processor is required. Per thread performance on somewhat affordable sparc boxes has not increased from the V240 through the T5220 while per-system performance has increased 10x or more. - In order to determine what is in a tar file, the entire thing needs to be read. If it was compressed, the entire tar file needs to be uncompressed (likely part of a pipeline) to see which files are in the archive. >From my recollection of the zap discussion and my own frustration with single-threaded performance on US-T1 systems, I would like to see: - All metadata at the beginning of the file. This is helpful when the file is delivered via a standard HTTP download (no IPS server) to determine which byte ranges need to be downloaded. - No barriers in the file format to having a multi-threaded pkg command that can simultaneously uncompress, checksum, verify signatures, etc. multiple files from the same package at the same time. Not forcing single-threaded operation would make it so that the use of more expensive compression algorithms (bzip2, 7zip?) and/or digital signatures is acceptable to a wider range of users. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
