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
>
>   


Reply via email to