Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> writes:
> Mark H Weaver <m...@netris.org> 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
