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 (russ...@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.
smime.p7s
Description: S/MIME Cryptographic Signature
