The following test case -- originally used to verify the fix of bug 1393419 (read-ahead not working if open-behind is turned on) -- shows that using read-ahead we get
worse performance than without it, in a scenario (sequential reading of a large file) that is typically expected to be benefited by read-ahead.

# Test setup

Reading a 2Gb sparse file. For each setup (ie. with or without
patch https://review.gluster.org/15811) and setting (of referred vol options)
we did alltogether 200 iteations, on 2 VM-s (100 + 100, ie. one VM with the
patch, one without, and switching after first 100 which has the patched setup).

read-ahead-page-count open-behind without patch (MiB/s) with patch (MiB/s)
1                     on          128.08                98.56
4                     on          128.98                88.71
16                    on          127.64                81.55
1                     off         108.55                108.52
4                     off         98.67                 99.93
16                    off         94.03                 94.99

# Results with read-ahead off

Note that the patch changes xlator order even in this case.

  • xlator order without patch:
     1. debug/io-stats
     2. performance/io-threads
     3. performance/md-cache
     4. performance/open-behind
     5. performance/quick-read
     6. performance/io-cache
     7. performance/readdir-ahead
     8. performance/write-behind
     9. cluster/distribute
    10. protocol/client
  • xlator order with patch:
     1. debug/io-stats
     2. performance/io-threads
     3. performance/md-cache
     4. performance/quick-read
     5. performance/io-cache
     6. performance/readdir-ahead
     7. performance/open-behind
     8. performance/write-behind
     9. cluster/distribute
    10. protocol/client

However, the above order change does not seem to make a difference.

open-behind without patch (MiB/s) with patch (MiB/s)
on          132.87                133.51
off         139.70                139.77

# Conclusion

Performance ordering of settings (approximate MiB/s):

  • no o/b & no r/a: 139
  • o/b only: 133
  • o/b only (r/a formally on but effectively disabled by o/b): 128
  • r/a only: 108
  • o/b & r/a (both working due to patch): 98