glusterfs.git/xlators/cluster/afr/src/afr-transaction.c, branch v3.4.0alpha2

cluster/afr: Avoid priv->eager_lock value update race

2013-02-06T17:25:42+00:00

Change-Id: I7049c0c64e36a9dfa4cc0e0b34de7ec111d2f6c1
BUG: 908302
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/4076
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Anand Avati

cluster/afr: Perform wakeup just before fop

2013-02-06T17:24:31+00:00

There is no necessity for the delayed-post-op to wait until
the next fop phase on the fd completes. Change-log,
locks are inherited by the time next fop phase is attempted
so the wakeup can happen just before the fop phase is started.

Change-Id: I0b8e591f591b0f7565eb55265ab51f476ed2b165
BUG: 908302
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/4073
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Anand Avati

afr: Modified book-keeping structures for entrylks

2013-01-23T17:17:00+00:00

* There are upto 3 entry lockees that may be needed to perform
  entrylk'ing in posix dir-write operations.

* For eg, rmdir ("/a/b") needs to acquire locks on two entities,
  - entrylk ("/a", "b")
  - entrylk ("/a/b", null)

* Changed existing entrylk/rename/selfheal (entrylk) transactions
  to use the new book-keeping structures

* Fixed few issues in afr_trace_entry_lk{in,out} functions. Tracing is now
  aware of the new entry lockee structure.

Implementation notes:
* Changed 'cookie' sent in stack_wind to encode lockee_entity_no
  and subvol_no.

  cookie is a non-negative integer such that 0 <= cookie < replica_count,
  When more than one lock is being acquired across the subvolumes,
  cookie % replica_count gives the subvol_no
  cookie / replica_count gives the lockee_entity_no.

Change-Id: Idbf41803387a7d59a0f7fcb1453d91cea74da153
BUG: 765564
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/2828
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/afr: Disable delayed post op when eager-lock is off

2013-01-18T23:57:56+00:00

Problem:
When eager-lock is disabled, inodelks for write-fops on same
fd conflict with each other. If eager-lock is disabled but
delayed post-op is enabled then each write fop's inodelk unlock
waits for post-op-delay-secs. So the conflicting write fop
acquires inodelk after post-op-delay-secs. This results in
post-op-delay-secs delay for every write fop on the fd for
sequential writes (Ex: dd).

Fix:
Disable delayed-post-op when eager-lock is off.

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

cluster/afr: Pre-op should be undone for non-piggyback post-op

2013-01-17T07:11:17+00:00

Problem:
When fop fails post-op is always performed
over the network irrespective of whether pre-op is piggybacked
or not. Decrementing Pre-op-done count even for the piggybacked
ones is wrong.
I have added an assert for pre_op_done to be non-zero and when
dd of=a if=/dev/urandom bs=5M count=1000 is executed and a brick
is taken down, the mount is crashing.

Fix:
Decrement pre-op-done count only when the post-op is not
piggybacked.

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

cluster/afr: mark new entry changelog for create/mknod failures

2012-12-04T22:50:52+00:00

Problem:
When create/mknod fails on some of the nodes, appropriate pending
data/metadata changelogs are not assigned. This was not considered
to be an issue because entry self-heal would do the assigning of
appropriate changelog after creating new entries. But using
the combination of rebalance and remove brick we can construct a
case where a file with same name and gfid can be created in a dir
with different data and link-to xattr without any changelog.

Fix:
When a create/mknod failure is observed mark the appropriate
changelog on the new file created.

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

afr: make flush non-transactional

2012-12-04T22:42:58+00:00

Flush is historically a transaction to ensure all previous writes
were complete. This is no longer required as write-behind has
learned to make flush a barrier operation (re: conversation w/
Avati).

Flush taking a full file lock causes VMs running on afr volumes
to stall when a migration occurs and self-heal is in progress.
Make afr_flush() a non-transactional operation.

BUG: 874045
Change-Id: If2db83823e280c86b1b29b41361eed7081601632
Signed-off-by: Brian Foster 
Reviewed-on: http://review.gluster.org/4261
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/afr: check transaction type for eager-lock after it is set

2012-11-21T20:03:37+00:00

Problem:
Eager locking lk-owner decision is taken before transaction
type is set. Default transaction type is DATA so all transactions
are treated as DATA transactions at the time of eager-locking
decision.

Fix:
Move the code that takes lk-owner decision after the transaction
type is set.

Test:
Checked that the transaction type is set properly in gdb at
the time of the lk-owner decision.

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

Preventing client crashing as the callings of GF_CALLOC has been failed.

2012-10-12T03:59:45+00:00

As the callings of GF_CALLOC can seldom come to a failure, glusterfs client
will crash due to segment fault. We should have returned once the variables
of transaction's local can't be alloced.

Change-Id: Ia3798b8349d832b23c7825e64dbad93ebe29cd1b
BUG: 861335
Signed-off-by: linbaiye 
Reviewed-on: http://review.gluster.org/4005
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/afr: check transaction type for eager-lock after it is set

2012-10-11T02:11:30+00:00

Problem:
Eager locking lk-owner decision is taken before transaction
type is set. Default transaction type is DATA so all transactions
are treated as DATA transactions at the time of eager-locking
decision.

Fix:
Move the code that takes lk-owner decision after the transaction
type is set.

Test:
Checked that the transaction type is set properly in gdb at
the time of the lk-owner decision.

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