+++ This bug was initially created as a clone of Bug #1091902 +++ Description of problem: ----------------------- fsync was one of the barrier class FOP, and it should be barrriered by the design of Barrier translator. That happened with FUSE protocol Weirdly, fsync on the NFS mount was successful and was not getting barriered Version-Release number of selected component (if applicable): ------------------------------------------------------------- mainline How reproducible: ----------------- Always Steps to Reproduce: ------------------- 1. NFS mount the volume 2. Create a file on the mount 3. Enable barrier 4. perform fsync operation on the file Actual results: --------------- fsync on the file happened successfully Expected results: ----------------- fsync should get barriered
RCA: barrier_fsync was not getting hit when fsync call is issued from the application over NFS mount. Investigation reveals that NFS doesn't send an explicit fsync call to the glusterfs server, however NFS converts it with a stable write with O_DSYNC flag, so for a fsync call over NFS mount point, barrier feature always needs to check for writev and its correspoding flags. So to meet all the coditions of write with O_SYNC and fsync getting blocked when barrier is enabled the check has been modified with following: if (!((flags | fd->flags) & (O_SYNC | O_DSYNC))) Point to be noted here is we need to check both fd's flag and the explicit flag as for NFS write fd->flags is 0. Fix http://review.gluster.org/#/c/7633/ is backported in downstream.
Verified with glusterfs-3.6.0.8-1.el6rhs Tested with following steps, Volume type - distributed replicate volume 1. NFS mount the volume 2. Create a file on the mount 3. Enable barrier on the volume 4. Perform fsync on the file Result - fysnc system call on the file was blocked Moving this bug as verified
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. http://rhn.redhat.com/errata/RHEA-2014-1278.html