glusterfs.git/xlators/features/locks/src, branch bug-deprecated

libglusterfs: change signature of syncop_(f)getxattr

2015-01-06T06:00:09+00:00

Pass xdata dict to syncop_(f)getxattr calls.

This patch [1/3] is required as a part of afr automated split-brain resolution
implementation.

Change-Id: I3970b3dd6daf64681a031e37f8e9afb14fb3d668
BUG: 1136769
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/9375
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Niels de Vos 
Tested-by: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Vijay Bellur

mgmt/glusterd: Add option to enable lock trace

2014-12-29T05:18:42+00:00

Change-Id: I24ed0f866d53e91a8323c043a38f73207cbfd7d2
BUG: 1168189
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/9351
Reviewed-by: Krutika Dhananjay 
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Krishnan Parthasarathi

features/locks: Add lk-owner checks in entrylk

2014-12-27T07:20:30+00:00

For backward compatibility of entry-self-heal we need
entrylks to be accepted by same lk-owner and same client.
This patch introduces these changes.

Change-Id: I67004cc5e657ba5ac09ceefbea823afdf06929e0
BUG: 1168189
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/9125
Reviewed-by: Krutika Dhananjay 
Tested-by: Gluster Build System

Changes in statedump for stack, frame, locks

2014-07-07T17:27:00+00:00

Internal call-stacks don't have lk-owner so it is a bit
difficult to confirm if a stack hung by comparing two
statedump files. This change prints call-stack, frame's
address. This should solve the comparison problem.

Lock times and log times don't have same timezone because
of which one has to manually convert the times for debugging
the issues. This change prints blocked, granted times also
in UTC.

Also fixed line truncation issue when client-unique-string
is big.

Change-Id: I116372c0d63476823a36ca6dbfba91648f9234cc
BUG: 1114188
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8197
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra Bhat 
Reviewed-by: Ravishankar N 
Reviewed-by: Vijay Bellur

features/locks: Clean up logging of cleanup in DISCONNECT codepath

2014-06-12T01:42:54+00:00

Now, gfid is printed as opposed to path in cleanup messages.

Also, refkeeper update is eliminated in inodelk and entrylk.
Instead, the patch ensures inode and pl_inode are kept alive as
long as there is atleast one lock (granted/blocked) on an inode.

Also, every inode is unref'd appropriately on a DISCONNECT from the
lock-owning client.

Change-Id: I531b1a02fe1b889fdd7f54b1fd522e78a18ed1df
BUG: 1104915
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/7981
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri

features/locks: Remove stale entrylk objects from 'blocked_locks' list

2014-04-26T07:52:25+00:00

* In the event of a DISCONNECT from a client, as part of cleanup,
  entrylk objects are not removed from the blocked_locks list before
  being unref'd and freed, causing the brick process to crash at
  some point when the (now) stale object is accessed again in the list.

* Also during cleanup, it is pointless to try and grant lock to a
  previously blocked entrylk (say L1) as part of releasing another
  conflicting lock (L2), (which is a side-effect of L1 not being
  deleted from blocked_locks list before grant_blocked_entry_locks()
  in cleanup) if L1 is also associated with the DISCONNECTing client.
  This patch fixes the problem.

Change-Id: I3d684c6bafc7e6db89ba68f0a2ed1dcb333791c6
BUG: 1089470
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/7560
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

features/locks: Remove stale inodelk objects from 'blocked_locks' list

2014-04-25T07:34:29+00:00

* In the event of a DISCONNECT from a client, as part of cleanup,
  inodelk objects are not removed from the blocked_locks list before
  being unref'd and freed, causing the brick process to crash at
  some point when the (now) stale object is accessed again in the list.

* Also during cleanup, it is pointless to try and grant lock to a
  previously blocked inodelk (say L1) as part of releasing another
  conflicting lock (L2), (which is a side-effect of L1 not being
  deleted from blocked_locks list before grant_blocked_inode_locks()
  in cleanup) if L1 is also associated with the DISCONNECTing client.
  This patch fixes the problem.

* Also, the codepath in cleanup of entrylks seems to be granting
  blocked inodelks, when it should be attempting to grant blocked
  entrylks, which is fixed in this patch.

Change-Id: I8493365c33020333b3f61aa15f505e4e7e6a9891
BUG: 1089470
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/7512
Reviewed-by: Raghavendra G 
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Anand Avati

build: MacOSX Porting fixes

2014-04-24T21:41:48+00:00

git@forge.gluster.org:~schafdog/glusterfs-core/osx-glusterfs

Working functionality on MacOSX

 - GlusterD (management daemon)
 - GlusterCLI (management cli)
 - GlusterFS FUSE (using OSXFUSE)
 - GlusterNFS (without NLM - issues with rpc.statd)

Change-Id: I20193d3f8904388e47344e523b3787dbeab044ac
BUG: 1089172
Signed-off-by: Harshavardhana 
Signed-off-by: Dennis Schafroth 
Tested-by: Harshavardhana 
Tested-by: Dennis Schafroth 
Reviewed-on: http://review.gluster.org/7503
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

features/locks: Fix a missing assignment in new_entrylk_lock()

2014-04-09T06:40:26+00:00

Change-Id: If5c03456d61ec930d588b57781fb545eed18e4a2
BUG: 1085220
Signed-off-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/7413
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Santosh Pradhan

locks: fix unconditional op_ret success of entrylk

2014-03-12T17:58:15+00:00

Bug introduced in recent refactoring. op_ret of entrylk() was always
getting set to 0 even though second locker wouldn't have gotten a lock.
This was resulting in multiple contenders to get locks granted at the
same time.

Change-Id: I99c187a9285fb80cc500b38f468f2ebda7048cab
Signed-off-by: Anand Avati 
BUG: 849630
Reviewed-on: http://review.gluster.org/7224
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY