Tweet
Well, BTRFS is OK (without workarounds) as of kernel 3.18 (so far...)
I find it ironic that NOW they go to EXT4 with OverlayFS, when the issues with performance and needing to do metadata rebalancing were resolved in the same 3.18 kernel release as the brand new OverlayFS is put in which presumably will introduce new/different issues... Switching a horse midstream brings its own issues, hopefully they don't make it worse with this switch...
This will probably help a few folks - what I've done as a workaround on older releases, is I have a scheduled job that I have setup on a Jenkins Continuous Integration server to do the following on the BTRFS mounts on the various servers:
btrfs balance start -dusage=20 /your_mountpoint_goes_here
If you don't put the -dusage on there, it'll rebalance the WHOLE thing, which gets into massively diminishing returns. The other early issue was too small a leaf/node size when creating the FS (it was 4K). A 16K leaf/node size is more appropriate, and oddly enough, reduces the metadata issues. 16K is now the default (as of btrfs-progs 3.12) so that is less of an issue as well. If you are unlucky enough to be running on defaults from an old btrfs package, you really do need to rebuild...
(If you don't have a Jenkins server in your IT shop, for handling admin tasks, take a look at it. Pretty awesome for crap like having to do scheduled workarounds on multiple servers simultaneously.)
I find it ironic that NOW they go to EXT4 with OverlayFS, when the issues with performance and needing to do metadata rebalancing were resolved in the same 3.18 kernel release as the brand new OverlayFS is put in which presumably will introduce new/different issues... Switching a horse midstream brings its own issues, hopefully they don't make it worse with this switch...
This will probably help a few folks - what I've done as a workaround on older releases, is I have a scheduled job that I have setup on a Jenkins Continuous Integration server to do the following on the BTRFS mounts on the various servers:
btrfs balance start -dusage=20 /your_mountpoint_goes_here
If you don't put the -dusage on there, it'll rebalance the WHOLE thing, which gets into massively diminishing returns. The other early issue was too small a leaf/node size when creating the FS (it was 4K). A 16K leaf/node size is more appropriate, and oddly enough, reduces the metadata issues. 16K is now the default (as of btrfs-progs 3.12) so that is less of an issue as well. If you are unlucky enough to be running on defaults from an old btrfs package, you really do need to rebuild...
(If you don't have a Jenkins server in your IT shop, for handling admin tasks, take a look at it. Pretty awesome for crap like having to do scheduled workarounds on multiple servers simultaneously.)
Comment