[Bugs] [Bug 1350867] RFE: FEATURE: Lock revocation for features/locks xlator

bugzilla at redhat.com bugzilla at redhat.com
Mon Jul 18 09:30:42 UTC 2016


https://bugzilla.redhat.com/show_bug.cgi?id=1350867



--- Comment #10 from Vijay Bellur <vbellur at redhat.com> ---
COMMIT: http://review.gluster.org/14816 committed in master by Pranith Kumar
Karampuri (pkarampu at redhat.com) 
------
commit 8cbee639520bf4631ce658e2da9b4bc3010d2eaa
Author: Richard Wareing <rwareing at fb.com>
Date:   Fri Nov 20 10:59:00 2015 -0800

    features/locks: Add lock revocation functionality to posix locks translator

    Summary:
    - Motivation: Prevents cluster instability by mis-behaving clients
      causing bricks to OOM due to inode/entry lock pile-ups.
    - Adds option to strip clients of entry/inode locks after N seconds
    - Adds option to clear ALL locks should the revocation threshold get hit
    - Adds option to clear all or granted locks should the max-blocked
      threshold get hit (can be used in combination w/ revocation-clear-all).
    - Options are:
        features.locks-revocation-secs <integer; 0 to disable>
        features.locks-revocation-clear-all [on/off]
        features.locks-revocation-max-blocked <integer>
    - Adds monkey-locking option to ignore 1% of unlock requests (dev only)
        features.locks-monkey-unlocking [on/off]
    - Adds logging to indicate revocation event & reason

    Test Plan:
    First you will need TWO fuse mounts for this repro.  Call them /mnt/patchy1
& /mnt/patchy2.

    1. Enable monkey unlocking on the volume:
    gluster vol set patchy features.locks-monkey-unlocking on

    2. From the "patchy1", use DD or some other utility to begin writing to a
file,
       eventually the dd will hang due to the dropped unlocked requests.  This
now
       simulates the broken client.  Run:

    for i in {1..1000};do dd if=/dev/zero of=/mnt/patchy1/testfile bs=1k
count=10;done'

    ...this will eventually hang as the unlock request has been lost.

    3. Goto another window and setup the mount "patchy2" @ /mnt/patchy2, and
       observe that 'echo "hello" >> /mnt/patchy2/testfile" will hang due to
the
       inability of the client to take out the required lock.

    4. Next, re-start the test this time enabling lock revocation; use a
timeout of
       2-5 seconds for testing:
       'gluster vol set patchy features.locks-revocation-secs <2-5>'

    5. Wait 2-5 seconds before executing step 3 above this time.  Observe that
this
       time the access to the file will succeed, and the writes on patchy1 will
       unblock until they hit another failed unlock request due to
       "monkey-unlocking".

    BUG: 1350867
    Change-Id: I814b9f635fec53834a26db634d1300d9a61057d8
    Signed-off-by: Pranith Kumar K <pkarampu at redhat.com>
    Reviewed-on: http://review.gluster.org/14816
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    Reviewed-by: Krutika Dhananjay <kdhananj at redhat.com>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
    Smoke: Gluster Build System <jenkins at build.gluster.org>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list