Hide Forgot
For RHEL 7 the default (target) resource group size was set to 2G but then a performance problem was discovered (bug #1154782) which caused the default size to be reverted to 256M in RHEL 7.1 (bug #1162817). We should reassess whether those performance issues have been solved and increase the default resource group size back to 2G when they are. fsck.gfs2 performance is also a factor here but, theoretically, fewer resource groups should allow fsck.gfs2 to go faster.
There may be an issue with performance at larger RG sizes with multiple processes. I ran a matrix of RG size vs processes and got these results: RG size procs bandwidth 256 1 539466KB/s 512 1 537059KB/s 1024 1 560422KB/s 2048 1 552481KB/s 256 3 472423KB/s 512 3 368493KB/s 1024 3 354238KB/s 2048 3 343896KB/s 256 6 508019KB/s 512 6 422882KB/s 1024 6 313730KB/s 2048 6 275803KB/s 256 12 546520KB/s 512 12 390912KB/s 1024 12 284684KB/s 2048 12 198894KB/s
Is that because they are all using the same rgrp? If each thread runs in a different top level dir (or subdir of a different top level dir) then does that issue go away?
You have a point. I figured out how to accomplish that with fio and here are the results: RG size procs bandwidth 256 1 537019KB/s 512 1 547736KB/s 1024 1 565922KB/s 2048 1 530186KB/s 256 3 606669KB/s 512 3 563094KB/s 1024 3 718381KB/s 2048 3 559343KB/s 256 6 665150KB/s 512 6 577753KB/s 1024 6 676871KB/s 2048 6 573286KB/s 256 12 666406KB/s 512 12 670210KB/s 1024 12 654321KB/s 2048 12 696050KB/s
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.