gluster-block now uses the improved eager-lock implementation to reduce the number of network operations. To get this effect on the old block hosting volumes  we need to enable cluster.eager-lock option after all the gluster pods are upgraded to the latest release.
# gluster volume set <volname> cluster.eager-lock on

Hello Manoj,
Any update on this, as qe is targetting to move all 331-async bugs to verified by tomorrow EOD?

With build:
glusterfs-fuse-3.8.4-54.14.el7rhgs.x86_64
gluster-block-0.2.1-20.el7rhgs.x86_64
glusterfs-libs-3.8.4-54.14.el7rhgs.x86_64
glusterfs-client-xlators-3.8.4-54.14.el7rhgs.x86_64
glusterfs-api-3.8.4-54.14.el7rhgs.x86_64
glusterfs-server-3.8.4-54.14.el7rhgs.x86_64
libtcmu-1.2.0-20.el7rhgs.x86_64
tcmu-runner-1.2.0-20.el7rhgs.x86_64
glusterfs-3.8.4-54.14.el7rhgs.x86_64
glusterfs-cli-3.8.4-54.14.el7rhgs.x86_64

Repeating the random write tests on a new setup. Only 3 systems available with 10GbE, so co-locating the client on one of the servers.

For a similar fio test I see:
glusterfs-fuse: 10610 IOPS
gluster-block: 9216 IOPS

So that looks good.

Also not seeing the write-amplification that we were seeing when the performance was poor (bz #1480188):
sdm               0.00     0.00    0.00 10504.60     0.00 42018.40 [at initiator]
sdb               0.00     4.00    0.00 10517.80     0.00 44974.05 [at brick]

Meaning given by first two sentences is a bit misleading.
It is: "Previously, eager-lock was disabled for volumes hosted by a block. Due to this reason, the conflicting writes were handled incorrectly"

But it is supposed to convey: "Previously, eager-lock was disabled for volumes hosted by a block because conflicting writes were handled incorrectly when eager-lock is enabled"

Rest of the doc-text looked okay.

It looks good to me. We don't need to explicitly say that it is enabled by default for new volumes?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:2222