+++ This bug was initially created as a clone of Bug #1332501 +++ Description of problem: Mandatory locks are differentiated from traditional advisory POSIX locks based on new structure member named 'lk_flags' within posix_lock_t structure. But during lock migration getactivelk() inside locks translator does not read lk_flags from this structure and hence this differentiation is lost on the destination brick after migration. Version-Release number of selected component (if applicable): mainline --- Additional comment from Vijay Bellur on 2016-05-03 18:24:57 IST --- REVIEW: http://review.gluster.org/14189 (core: Honour mandatory lock flags during lock migration) posted (#1) for review on master by Anoop C S (anoopcs) --- Additional comment from Vijay Bellur on 2016-05-04 12:43:57 IST --- REVIEW: http://review.gluster.org/14189 (core: Honour mandatory lock flags during lock migration) posted (#2) for review on master by Anoop C S (anoopcs)
REVIEW: http://review.gluster.org/14457 (core: Honour mandatory lock flags during lock migration) posted (#1) for review on release-3.8 by Anoop C S (anoopcs)
COMMIT: http://review.gluster.org/14457 committed in release-3.8 by Niels de Vos (ndevos) ------ commit fc7e423d8ccbec96a4ebc5fcda6d92dc6fc59174 Author: Anoop C S <anoopcs> Date: Tue May 3 17:02:17 2016 +0530 core: Honour mandatory lock flags during lock migration lk_flags from posix_lock_t structure is the primary key used to differentiate locks as either advisory and mandatory type. During lock migration this field is not read in getactivelk() call path. So in order to copy the exact lock state from source to destination it is necessary to include lk_flags within lock_migration_info_t structure to maintain accurate state. This change also includes minor modifications to setactivelk() call to consider lk_flags during lock migration. > Reviewed-on: http://review.gluster.org/14189 > Smoke: Gluster Build System <jenkins.com> > Reviewed-by: Susant Palai <spalai> > Reviewed-by: Poornima G <pgurusid> > NetBSD-regression: NetBSD Build System <jenkins.org> > CentOS-regression: Gluster Build System <jenkins.com> > Reviewed-by: Pranith Kumar Karampuri <pkarampu> (cherry picked from commit deaf8439fc42435988aae6a7b9ab681cc0d36b09) Change-Id: I20a7b6b6a0f3bdac5734cce8a2cd2349eceff195 BUG: 1337805 Signed-off-by: Anoop C S <anoopcs> Reviewed-on: http://review.gluster.org/14457 Smoke: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.com> Reviewed-by: Pranith Kumar Karampuri <pkarampu>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.8.0, please open a new bug report. glusterfs-3.8.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user