Goffredo Baroncelli <kreij...@libero.it> posted on Thu, 12 Jun 2014 13:13:26 +0200 as excerpted:
>>systemd has a very stupid journal write pattern. It checks if there is >>space in the file for the write, and if not it fallocates the small >>amount of space it needs (it does *4 byte* fallocate calls!) and then >>does the write to it. All this does is fragment the crap out of the log >>files because the filesystems cannot optimise the allocation patterns. > > I checked the code, and to me it seems that the fallocate() are done in > FILE_SIZE_INCREASE unit (actually 8MB). FWIW, either 4 byte or 8 MiB fallocate calls would be bad, I think actually pretty much equally bad without NOCOW set on the file. Why? Because btrfs data blocks are 4 KiB. With COW, the effect for either 4 byte or 8 MiB file allocations is going to end up being the same, forcing (repeated until full) rewrite of each 4 KiB block into its own extent. Turning off the fallocate should allow btrfs to at least consolidate a bit, tho to the extent that multiple 4 KiB blocks cannot be written, repeated fsync will still cause issues. 80-100 MiB logs (size mentioned in another reply) should be reasonably well handled by btrfs autodefrag, however, if it's turned on. I'd be worried if sizes were > 256 MiB and certainly as sizes approached a GiB, but it should handle 80-100 MiB just fine. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
