Re: [Bug-tar] [PATCH] Remove nonportable check for files containing only zeroes

[Mark H Weaver]

Joerg Schilling <address@hidden> writes:

> Mark H Weaver <address@hidden> wrote:
>
>> > Now many bytes have been written past the hole?
>>
>> Did you read my entire message?  The answer to your question was just a
>> few lines beyond the excerpt that you quoted above.  I wrote:
>>
>> >> Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written,
>> >> mostly sparse file with size > 8G, using linux-libre-4.14.14.  More
>> >> specifically, the "storing sparse files > 8G" test in tar's test suite
>> >> reliably fails on my system:
>> >> 
>> >>   140: storing sparse files > 8G                       FAILED 
>> >> (sparse03.at:29)
>> >> 
>> >> The test creates a sparse file consisting of 8 gibibytes of hole
>> >> followed by 512 bytes of 'A's at the end.  [...]
>
> Sorry, I did not see this.
>
> Well then it would be of interest whether btrfs is able to keep 512 bytes of 
> data in the meta data space.

A hypothetical file system might store the entire file contents
*compressed* in the inode.  Large holes might be stored quite compactly
in such a scheme.  It's not hard to imagine a realistic compression
method that could successfully store 8 gigibytes of zeroes followed by
512 bytes of 'A's, completely within the inode.

In such a file system, even in the absence of delayed allocation,
(st_blocks == 0) would be justifiable, no?

       Mark