It seems to me that there has been enough real discussion on this topic,
that I think it is worth promoting to at least a fast track status.
Please consider it so promoted, and set the time out for a week from
Wednesday. (A longer timeout than 1 week is appropriate, IMO, given
that this week represents a short week in the US.)
-- Garrett
Joerg Schilling wrote:
> Don Cragun <don.cragun at sun.com> wrote:
>
>
>> and in the EXTENDED DESCRIPTION, where it says:
>>
>> "SUN.holesdata A Solaris extension to pax extended header
>> keywords. Specifies the data and hole pairs
>> for a sparse file.
>>
>>
> ...
>
>
>> 49 SUN.holesdata= 0 8192 24576 32768 49152 49159
>>
>
> I just verified this on a recent build and it seems that Sun pax now contains
> a similar conceptional problem as the GNU tar guys did introduce a few years
> ago:
>
> The size of the POSIX.1-2001 file metadata is limited to 8 GB. Putting the
> hole information into the file meta data area thus limits the number of holes.
>
> If you e.g. create a file with the maximum holyness (Block size == 8k),
> you are able to archive a file of up to ~ 5 TB and aprox. 300 million holes.
> I know that an archiver that is going to unpack this would need to allocate
> 5 GB of virtual memory to remember the hole list. Files that fall into this
> category are already possible today, so this does not seem to be ready for the
> future.
>
> I recommend to fix this by moving the hole information into the file data
> area,
> to switch to a offset/datasize notation (to reduce the size) and to write
> the information as comma separated pairs.
>
>
> J?rg
>
>
