Re: new database files not compressed

[Nikolay Borisov <nborisov@suse.com>]

On 2.09.20 г. 9:05 ч., Hamish Moffatt wrote:
> On 2/9/20 3:57 pm, Nikolay Borisov wrote:
>>
>> On 2.09.20 г. 3:32 ч., Hamish Moffatt wrote:
>>>
>>> I've been able to reproduce this with a trivial test program which
>>> mimics the I/O behaviour of Firebird.
>>>
>>> It is calling fallocate() to set up a bunch of blocks and then writing
>>> them with pwrite(). It seems to be the fallocate() step which is
>>> preventing compression.
>>>
>>> Here is my trivial test program which just writes zeroes to a file. The
>>> output file does not get compressed by btrfs.
>> Ag yes, this makes sense, because fallocate creates PREALLOC extents
>> which are NOCOW (since they are essentially empty so it makes no sense
>> to CoW them) hence they go through a different path which doesn't
>> perform compression.
> 
>>>      for (int count = 0; count < 256; ++count) {
>>>          if (count % 8 == 0)
>>>              fallocate(fd, 0, count * BLOCK_SIZE, 8 * BLOCK_SIZE);
>>>          pwrite(fd, buf, BLOCK_SIZE, count * BLOCK_SIZE);
>>>      }
> 
> 
> OK, and they can't be compressed when data is written to those extents
> afterwards?

Yes, compression entails creating NEW extents. But with falloc extents
are created during the fallloc operation so when you issue subsequent
writes into the prealloc range you simply write the data to disk and not
bother with metadata management.

> 
> 
> Thanks, it's good to understand why it's not working for Firebird.
> 
> 
> Hamish
>