Bug 1100571

Summary:	[barrier] fsync on NFS mount was not barriered, when barrier was enabled
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Atin Mukherjee <amukherj>
Component:	core	Assignee:	Atin Mukherjee <amukherj>
Status:	CLOSED ERRATA	QA Contact:	SATHEESARAN <sasundar>
Severity:	high	Docs Contact:
Priority:	high
Version:	rhgs-3.0	CC:	amukherj, gluster-bugs, kaushal, kparthas, nsathyan, rhs-bugs, sasundar, sdharane, storage-qa-internal
Target Milestone:	---
Target Release:	RHGS 3.0.0
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.6.0.3-1.el6rhs	Doc Type:	Bug Fix
Doc Text:	fsync calls on NFS mount were not blocked, when barrier was enabled. This is because NFS handles fsync calls differently. Now with this fix, fsync calls on NFS mount will be blocked, when barrier was enabled.	Story Points:	---
Clone Of:	1091902	Environment:
Last Closed:	2014-09-22 19:39:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1091902
Bug Blocks:

Description Atin Mukherjee 2014-05-23 06:43:41 UTC

+++ 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

Comment 2 Atin Mukherjee 2014-05-23 06:54:19 UTC

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.

Comment 3 SATHEESARAN 2014-05-30 04:55:37 UTC

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

Comment 6 errata-xmlrpc 2014-09-22 19:39:17 UTC

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