Bug 1272331 - Tier: Do not promote/demote files on which POSIX locks are held
Tier: Do not promote/demote files on which POSIX locks are held
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: tiering (Show other bugs)
3.7.5
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: bugs@gluster.org
bugs@gluster.org
:
Depends On: 1271148
Blocks: 1273260 glusterfs-3.7.6
  Show dependency treegraph
 
Reported: 2015-10-16 02:50 EDT by Nithya Balachandran
Modified: 2015-11-17 01:00 EST (History)
4 users (show)

See Also:
Fixed In Version: glusterfs-3.7.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1271148
: 1273260 (view as bug list)
Environment:
Last Closed: 2015-11-17 01:00:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nithya Balachandran 2015-10-16 02:50:25 EDT
+++ This bug was initially created as a clone of Bug #1271148 +++

Description of problem:
The dht_migrate_file function currently does not move the POSIX locks on the file being migrated to the dst file. Any locks held on a file are lost once the migration is complete. 

This problem exists in DHT rebalance but is magnified in tiering as promotes and demotes occur more frequently.

BZ 1267955 tracks the lock migration fix. Until that is done, we will skip all files on which POSIX locks are held.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Vijay Bellur on 2015-10-13 05:51:50 EDT ---

REVIEW: http://review.gluster.org/12347 (cluster/dht : Do not migrate files with POSIX locks held) posted (#1) for review on master by N Balachandran (nbalacha@redhat.com)

--- Additional comment from Vijay Bellur on 2015-10-14 06:58:34 EDT ---

REVIEW: http://review.gluster.org/12347 (cluster/dht : Do not migrate files with POSIX locks held) posted (#2) for review on master by N Balachandran (nbalacha@redhat.com)

--- Additional comment from Vijay Bellur on 2015-10-14 07:10:48 EDT ---

REVIEW: http://review.gluster.org/12347 (cluster/dht : Do not migrate files with POSIX locks held) posted (#3) for review on master by N Balachandran (nbalacha@redhat.com)

--- Additional comment from Vijay Bellur on 2015-10-15 09:08:41 EDT ---

COMMIT: http://review.gluster.org/12347 committed in master by Dan Lambright (dlambrig@redhat.com) 
------
commit bd71446b25aefe066ca18a28d73d777774ab7f87
Author: N Balachandran <nbalacha@redhat.com>
Date:   Tue Oct 13 15:02:00 2015 +0530

    cluster/dht : Do not migrate files with POSIX locks held
    
    dht_migrate_file does not migrate file locks to the dst file.
    Any locks held on the source file are lost once the migration
    is complete. This issue is magnified in the case of a tier volume
    as file migrations occur more frequently and repeatedly as compared
    to a DHT rebalance.
    
    The fix makes 2 changes:
    1. Before starting the actual migration process, check if there are
     any locks held on the file. If yes, do not migrate the file.
    2. The rebalance process tries to lock on the entire file just before
     moving into the Phase 2 of the file migration. If the lock acquisition
    fails, the file migration does not proceed.
    If the lock is granted, the file migration proceeds.
    
    This still leaves a small window where conflicting locks can be granted to
    different clients. If client1 requests a lock on the src file just after
    it is converted to a linkto file and client2 requests a lock on the dst
    data file, they will both be granted, but all FOPs will be redirected
    to the dst data file. This issue will be taken up in a subsequent patch.
    
    Change-Id: I8c895fc3cced50dd2894259d40a827c7b43d58ac
    BUG: 1271148
    Signed-off-by: N Balachandran <nbalacha@redhat.com>
    Reviewed-on: http://review.gluster.org/12347
    Tested-by: NetBSD Build System <jenkins@build.gluster.org>
    Tested-by: Gluster Build System <jenkins@build.gluster.com>
    Reviewed-by: Dan Lambright <dlambrig@redhat.com>
    Tested-by: Dan Lambright <dlambrig@redhat.com>
Comment 1 Vijay Bellur 2015-10-16 05:42:36 EDT
REVIEW: http://review.gluster.org/12369 (cluster/dht : Do not migrate files with POSIX locks held) posted (#1) for review on release-3.7 by N Balachandran (nbalacha@redhat.com)
Comment 2 Vijay Bellur 2015-10-18 10:25:13 EDT
COMMIT: http://review.gluster.org/12369 committed in release-3.7 by Dan Lambright (dlambrig@redhat.com) 
------
commit 66992a18e06105dfe6f7a14b1f30227f985a94bc
Author: N Balachandran <nbalacha@redhat.com>
Date:   Fri Oct 16 15:10:28 2015 +0530

    cluster/dht : Do not migrate files with POSIX locks held
    
    dht_migrate_file does not migrate file locks to the dst file.
    Any locks held on the source file are lost once the migration
    is complete. This issue is magnified in the case of a tier volume
    as file migrations occur more frequently and repeatedly as compared
    to a DHT rebalance.
    
    The fix makes 2 changes:
    1. Before starting the actual migration process, check if there are
     any locks held on the file. If yes, do not migrate the file.
    2. The rebalance process tries to lock on the entire file just before
     moving into the Phase 2 of the file migration. If the lock acquisition
    fails, the file migration does not proceed.
    If the lock is granted, the file migration proceeds.
    
    This still leaves a small window where conflicting locks can be granted to
    different clients. If client1 requests a lock on the src file just after
    it is converted to a linkto file and client2 requests a lock on the dst
    data file, they will both be granted, but all FOPs will be redirected
    to the dst data file. This issue will be taken up in a subsequent patch.
    
    Change-Id: I8c895fc3cced50dd2894259d40a827c7b43d58ac
    BUG: 1272331
    Signed-off-by: N Balachandran <nbalacha@redhat.com>
    > Reviewed-on: http://review.gluster.org/12347
    > Tested-by: NetBSD Build System <jenkins@build.gluster.org>
    > Tested-by: Gluster Build System <jenkins@build.gluster.com>
    > Reviewed-by: Dan Lambright <dlambrig@redhat.com>
    > Tested-by: Dan Lambright <dlambrig@redhat.com>
    > Signed-off-by: N Balachandran <nbalacha@redhat.com>
    Reviewed-on: http://review.gluster.org/12369
    Tested-by: Gluster Build System <jenkins@build.gluster.com>
    Tested-by: NetBSD Build System <jenkins@build.gluster.org>
    Reviewed-by: Dan Lambright <dlambrig@redhat.com>
    Tested-by: Dan Lambright <dlambrig@redhat.com>
Comment 3 Raghavendra Talur 2015-11-17 01:00:20 EST
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.7.6, please open a new bug report.

glusterfs-3.7.6 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://www.gluster.org/pipermail/gluster-users/2015-November/024359.html
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Note You need to log in before you can comment on or make changes to this bug.