glusterfs.git/xlators/features/locks/src/inodelk.c, branch v3.5beta1

client_t: phase 2, refactor server_ctx and locks_ctx out

2013-10-31T16:32:50+00:00

remove server_ctx and locks_ctx from client_ctx directly and store as
into discrete entities in the scratch_ctx

hooking up dump will be in phase 3

BUG: 849630
Change-Id: I94cea328326db236cdfdf306cb381e4d58f58d4c
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/5678
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

features/locks : Improves debuggability of inode/entry locks.

2013-09-03T13:50:40+00:00

Prints, in the statedump, the information about the mount that
performed the inode/entry lk.

For the entrylks that are granted after a blocked state, the
blocked time is not printed. A patch for that will be sent
later.

Change-Id: Ib0c1ed21fa9328b435f96b590dd343f59814a08d
BUG: 915629
Signed-off-by: Anuradha Talur 
Reviewed-on: http://review.gluster.org/5712
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

features/locks: Convert old style metadata locks to new-style

2013-08-07T10:33:22+00:00

Problem:
In 3.3, inode locks of both metadata and data are competing in same
domain called data domain (old style). This coupled with eager-lock,
delayed post-ops introduce delays for metadata operations like chmod,
chown etc. To avoid this problem, inode locks for metadata ops are
moved to different domain called metadata domain in 3.4 (new style).
But when both 3.3 clients and 3.4 clients are present, 3.4 clients
for metadata operations still need to take locks in "old style" so
that proper synchronization happens across 3.3 and 3.4 clients. Only
when all clients are >= 3.4 locks will be taken in "new style" for
metadata locks. Because of this behavior as long as at least one 3.3
client is present, delays will be perceived for doing metadata
operations on all 3.4 clients while data operations are in
progress (Ex: Untar will untar one file per sec).

Fix:
Make locks xlators translate old-style metadata locks to new-style
metadata locks. Since upgrade process suggests upgrading servers
first and then clients, this approach gives good results.

Tests:
1) Tested that old style metadata locks are converted to new style by
   locks xlator using gdb
2) Tested that disconnects purge locks in meta-data domain as well
   using gdb and statedumps.
3) Tested that untar performance is not hampered by meta-data and
   data operations.
4) Had two mounts one with orthogonal-meta-data on and other with
   orthogonal-meta-data off ran chmod 777  on one mount and
   chmod 555  on the other mount in while loops when I took
   statedumps I saw that both the transports are taking lock on
   same domain with same range.

   18:49:30 :) ⚡ sudo grep -B1 "ACTIVE" /usr/local/var/run/gluster/home-gfs-r2_0.324.dump.*
   home-gfs-r2_0.324.dump.1375794971-lock-dump.domain.domain=r2-replicate-0:metadata
   home-gfs-r2_0.324.dump.1375794971:inodelk.inodelk[0](ACTIVE)=type=WRITE, whence=0, start=9223372036854775806, len=0, pid = 7525, owner=78f9e652497f0000, transport=0x15ac9e0, , granted at Tue Aug  6 18:46:11 2013

   home-gfs-r2_0.324.dump.1375795051-lock-dump.domain.domain=r2-replicate-0:metadata
   home-gfs-r2_0.324.dump.1375795051:inodelk.inodelk[0](ACTIVE)=type=WRITE, whence=0, start=9223372036854775806, len=0, pid = 8879, owner=0019cc3cad7f0000, transport=0x158f580, , granted at Tue Aug  6 18:47:31 2013

Change-Id: I268df4efd93a377a0c73fbc59b739ef12a7a8bb6
BUG: 993981
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/5503
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

locks: Added an xdata-based 'cmd' for inodelk count in a given domain

2013-07-18T08:38:16+00:00

Following is the semantics of the 'cmd':
1) If @domain is NULL - returns no. of locks blocked/granted in all domains
2) If @domain is non-NULL- returns no. of locks blocked/granted in that
domain
3) If @domain is non-existent - returns '0'; This is important since
locks xlator creates a domain in a lazy manner.

where @domain - a string representing the domain.

Change-Id: I5e609772343acc157ca650300618c1161efbe72d
BUG: 951195
Original-author: Krishnan Parthasarathi 
Signed-off-by: Krishnan Parthasarathi 
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.org/4889
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

All: License message change

2012-09-13T20:19:37+00:00

License message changed for server-side, dual license GPLV2 and LGPLv3+.

Change-Id: Ia9e53061b9d2df3b3ef3bc9778dceff77db46a09
BUG: 852318
Signed-off-by: Varun Shastry 
Reviewed-on: http://review.gluster.org/3940
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Anand Avati

All: License message change

2012-08-28T10:45:06+00:00

The license message is changed to
  Copyright (c) 2008-2012 Red Hat, Inc. 
  This file is part of GlusterFS.

  This file is licensed to you under your choice of the GNU Lesser
  General Public License, version 3 or any later version (LGPLv3 or
  later), or the GNU General Public License, version 2 (GPLv2), in all
  cases as published by the Free Software Foundation.

Change-Id: I07d2b63ed5fbbbd1884f1e74f2dd56013d15b0f4
BUG: 852318
Signed-off-by: Varun Shastry 
Reviewed-on: http://review.gluster.org/3858
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

features/locks: Fix statedump code

2012-07-29T20:40:19+00:00

RCA:
Taking blocking mutex/spin locks lead to dead locks
because of the locking order in statedumps. Also we
were asked to remove gf_logs if possible to avoid extra
cost in signal handlers.

Fix:
changed blocking mutes/spin locks to their non-blocking variants.
Removed gf_logs in locks xlator statedump code-path.

Tests:
State-dump success cases are working fine.
Triggered try-lock failures by putting statedumps in a while loop.
In parallel did chown of the same file in a while loop.

Change-Id: I81539a62f8216f267f57bb703ef132c85bfd557d
BUG: 843781
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.com/3747
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

remove useless if-before-free (and free-like) functions

2012-07-13T21:03:42+00:00

See comments in http://bugzilla.redhat.com/839925 for
the code to perform this change.

Signed-off-by: Jim Meyering 
BUG: 839925
Change-Id: I10e4ecff16c3749fe17c2831c516737e08a3205a
Reviewed-on: http://review.gluster.com/3661
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

core: adding extra data for fops

2012-03-22T23:40:27+00:00

with this change, the xlator APIs will have a dictionary as extra
argument, which is passed between all the layers. This can be
utilized for overloading in some of the operations.

Change-Id: I58a8186b3ef647650280e63f3e5e9b9de7827b40
Signed-off-by: Amar Tumballi 
BUG: 782265
Reviewed-on: http://review.gluster.com/2960
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

features/locks: Avoid race in creating domains

2012-03-21T18:15:15+00:00

Thread:1                 |       Thread:2
-----------------------------------------
1) Does inodelk on inode1| 1) Does inodelk on inode1
2) It tries to get the   | 2) It tries to get the
dom object for the volume| dom object for the volume
volname-replicate-0. But | volname-replicate-0. But
the domain list is empty.| the domain list is empty.
3) Create the new domain |
dom1 and add it to head  |
of the list of domains.  |
4) inodelk happens on    | 3) Create the new domain
dom1 on range r1.        | dom2 and add it to head
                         | of the list of domains.
                         | 4) inodelk happens on dom2 on range r2
5) unlock for r1 comes   | 5) Unlock on r2 succeeds.
on inode1.               |
6) It tries to get the   |
domain, of the inodelk   |
for volume               |
volname-replicate-0, gets|
dom2 but the lock on     |
range r1 is not present  |
so it fails.             |

subsequent inode lock, unlocks will keep happening on the domain dom2.
The stale lock present in the dom1 on range r1 will live on.
It wont cause any hangs, but the statedump will always be scary.

Change-Id: I9adc120d33febf685b30859cc307768c2fc63ae5
BUG: 770080
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.com/2993
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Anand Avati