[systemd-devel] journal fragmentation on Btrfs

[Andrei Borzenkov]

22.04.2017 15:29, Andrei Borzenkov пишет:
> 18.04.2017 07:27, Chris Murphy пишет:
>> On Mon, Apr 17, 2017 at 10:05 PM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
>>> 18.04.2017 06:50, Chris Murphy пишет:
>>
>>>>> What exactly "changes" mean? Write() syscall?
>>>>
>>>> filefrag reported entries increase, it's using FIEMAP.
>>>>
>>>
>>> So far it sounds like btrfs allocates new extent on every write to
>>> journal file. Each journal record itself is relatively small indeed.
>>
>> Hence why it would be better if there's no fsync so that it can
>> accumulate these and do its own commit (30s default for Btrfs) and let
>> them accumulate.
>>
> 
> It is not related to fsync. I made some tests. Journald does not appear
> to preallocate file nor mmap the whole file (at least as far as I can
> see from the source); when it appends new record it basically does
> 
> fallocate (fd, end_of_file, new_size)
> mmap (fd, end_of_file, new_size)
> write to new size
> 
> This results in large number of extents as each fallocate() ends up in
> new extent.
> 
> I can easily reproduce it with small program that is using similar
> pattern; actually mmap is also red herring. Just fallocat'ing file in
> small increments gives file consisting of overly large number of
> extents. How exactly those extents get distributed across device
> probably depends on overall filesystem activity.
> 
> This is different from simply writing to file at the end, which still
> results in several extent, but significantly larger.
> 
> BTW you get the same pattern from direct IO. Writing 100M file in 4K
> blocks using cached writes gives me here 7 extents of size between 25M
> and 500K. Writing the same with direct IO results in 25600 extents (same
> as growing file in 4K steps with fallocate).
> 

For comparison - on ext4 both direct IO and fallocate ends in 2-3
extents. On xfs fallocate gives 2 extents (the first being very small)
and direct IO - 1 extent.