Description of problem: ----------------------- "cp -a" operation should not be blocked while enabling barrier. But this happens to be the case with NFS mount Version-Release number of selected component (if applicable): ------------------------------------------------------------- mainline How reproducible: ----------------- Always Steps to Reproduce: ------------------- 0. NFS mount the volume on the client 1. Enable barrier 2. Perform "cp -a" operation on the mount Actual results: ---------------- "cp -a" operation gets barriered on NFS mount Expected results: ------------------ "cp -a" operation should not get barriered
After discussing with the NFS team, what I understood is a write from NFS would always have O_DSYNC flag set which is a sync write to glusterfs and as per the barrier class fops, we are supposed to block it if barrier is enabled. 'cp -a' eventually have writev call and because of which this gets hung. I will double confirm it with the team again and will keep posted.
(In reply to Atin Mukherjee from comment #1) > After discussing with the NFS team, what I understood is a write from NFS > would always have O_DSYNC flag set which is a sync write to glusterfs [Santosh] This is not quite correct. There is no fsync call in NFS protocol. That gets converted into WRITE call with O_SYNC/O_DSYNC flags which would instruct backend to go for stable write (means flush to disk). For async WRITEs NFS does not send the FILE_SYNC. Instead it heavily depends on the NFS client VM subsystem i.e. whenever VM subsystem flushes the page caches, it would issue the NFS server the WRITE call with FILE_SYNC flag (i.e. stable write). It depends on the vm.dirty_ratio or its related VM settings. But if the file is opened with O_DIRECT, then every write would generate a NFS WRITE call with FILE_SYNC enabled. Gluster NFS sends every WRITE with size 1MB (by default). So if you write lesser data, then you may see one WRITE call with FILE_SYNC flag. > per the barrier class fops, we are supposed to block it if barrier is > enabled. 'cp -a' eventually have writev call and because of which this gets > hung. I will double confirm it with the team again and will keep posted.