Re: [systemd-devel] Slow startup of systemd-journal on BTRFS

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

On 2014-06-16 06:35, Russell Coker wrote:
> On Mon, 16 Jun 2014 12:14:49 Lennart Poettering wrote:
>> On Mon, 16.06.14 10:17, Russell Coker (russell@coker.com.au) wrote:
>>>> I am not really following though why this trips up btrfs though. I am
>>>> not sure I understand why this breaks btrfs COW behaviour. I mean,
>>>> fallocate() isn't necessarily supposed to write anything really, it's
>>>> mostly about allocating disk space in advance. I would claim that
>>>> journald's usage of it is very much within the entire reason why it
>>>> exists...
>>>
>>> I don't believe that fallocate() makes any difference to fragmentation on
>>> BTRFS.  Blocks will be allocated when writes occur so regardless of an
>>> fallocate() call the usage pattern in systemd-journald will cause
>>> fragmentation.
>>
>> journald's write pattern looks something like this: append something to
>> the end, make sure it is written, then update a few offsets stored at
>> the beginning of the file to point to the newly appended data. This is
>> of course not easy to handle for COW file systems. But then again, it's
>> probably not too different from access patterns of other database or
>> database-like engines...
> 
> Not being too different from the access patterns of other databases means 
> having all the same problems as other databases...  Oracle is now selling ZFS 
> servers specifically designed for running the Oracle database, but that's with 
> "hybrid storage" "flash" (ZIL and L2ARC on SSD).  While BTRFS doesn't support 
> features equivalent for ZIL and L2ARC it's easy to run a separate filesystem 
> on SSD for things that need performance (few if any current BTRFS users would 
> have a database too big to entirely fit on a SSD).
> 
> The problem we are dealing with is "database-like" access patterns on systems 
> that are not designed as database servers.
> 
> Would it be possible to get an interface for defragmenting files that's not 
> specific to BTRFS?  If we had a standard way of doing this then systemd-
> journald could request a defragment of the file at appropriate times.
> 
While this is a wonderful idea, what about all the extra I/O this will
cause (and all the extra wear on SSD's)?  While I understand wanting
this to be faster, you should also consider the fact that defragmenting
the file on a regular basis is going to trash performance for other
applications.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]