Re: new database files not compressed

A L
2020-09-03T15:04:52Z

On 2020-09-02 12:09, Nikolay Borisov wrote:
>
> On 2.09.20 г. 12:57 ч., A L wrote:
>>
>> ---- From: Nikolay Borisov <nborisov@suse.com> -- Sent: 2020-09-02 - 07:57 ----
>>>> 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.
>>>
>> Hi,
>>
>> This is interesting. I think that a lot of applications use fallocate in their normal operations. This is probably why we see weird compsize results every now and then.
>>
>> A file that is nocow will also not have checksums. Is this true for these fallocated files (that has data written to them) too?
> No, fallocated files will have checksums. It's just that compression is
> not integrated into it. BTRFS is an open source project so patches are
> welcomed.
>
Is it a very big task to add the compression code path here, since we
already do checksums?