glusterfs.git/xlators/cluster/ec/src/ec-common.c, branch v3.7.14

cluster/ec: Fix race in timer cancellation

2016-07-18T06:29:05+00:00

A race in timer cancellation for delayed unlock could cause a crash
if the cancelling thread fails to cancel the timer because it has
already been fired but not executed, and the callback is scheduled
out of the CPU, delaying it until the thread has released important
resources needed by the callback.

This patch improves the handling of this case to make it robust.

Backport of:
> Change-Id: I5c8a8c6610c5136f71b938aa78b5878ba05238d4
> BUG: 1345855
> Signed-off-by: Xavier Hernandez 
> Reviewed-on: http://review.gluster.org/14712
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Pranith Kumar Karampuri 

Change-Id: I5c8a8c6610c5136f71b938aa78b5878ba05238d4
BUG: 1346156
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/14724
Smoke: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

cluster/ec: Fix invalid __fd_unref() call

2016-06-14T01:03:50+00:00

__fd_unref() doesn't do any cleanup, so it cannot be called to release
fd references, specially if it's the last reference.

The code has been changed to avoid a call to this function.

In the previous version we always tried to keep the newest fd in the
ec_lock_t structure. However this is not necessary. We'll always keep
one reference to an open file on the same inode. It's irrelevant if
the reference is new or old.

The function __fd_unref() has also been removed from fd.h to avoid being
used in the future since it's useless as it's defined now.

Backport of http://review.gluster.org/14683

Change-Id: Ia728777fc8e464758d5ea4d3bf020f0603919039
BUG: 1344422
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/14685
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

cluster/ec: Fix issues with eager locking

2016-05-04T11:29:04+00:00

Due to a race in timer cancellation, in some cases it was possible
to unlock the lock while another concurrent fop that needed it
continues execution as if it were not released.

This patch also fixes an issue that caused a lock to not be released
if an error was found while preparing ec_update_size_version().

> Change-Id: I1344a3f5ecfc333f05a09e62653838264c9c26b1
> BUG: 1331254
> Signed-off-by: Xavier Hernandez 
> Reviewed-on: http://review.gluster.org/14112
> Smoke: Gluster Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Chen Chen 
> NetBSD-regression: NetBSD Build System 

Change-Id: I21edd17d914dfa8d2f98e6bbde50830496e12a92
BUG: 1330132
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/14174
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

cluster/ec: Provide an option to enable/disable eager lock

2016-03-21T05:52:53+00:00

Problem: If a fop takes lock, and completes its operation,
it waits for 1 second before releasing the lock. However,
If ec find any lock contention within this time period,
it release the lock immediately before time expires. As we
take lock on first brick, for few operations, like read, it
might happen that discovery of lock contention might take
long time and can degrades the performance.

Solution: Provide an option to enable/disable eager lock.
If eager lock is disabled, lock will be released as soon
as fop completes.

gluster v set  disperse.eager-lock on
gluster v set  disperse.eager-lock off

master-
http://review.gluster.org/13605

Change-Id: I000985a787eba3c190fdcd5981dfbf04e64af166
BUG: 1318965
Signed-off-by: Ashish Pandey 
Reviewed-on: http://review.gluster.org/13773
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

cluster/ec: Fix invalid config check for directories

2016-03-02T11:02:49+00:00

The trusted.ec.config xattr is not defined for directories. However
sometimes it could be requested because the inode type of a directory
can temporarily be IA_INVAL.

Requesting such xattr using the xattrop fop when it doesn't exist,
returns a config value full of 0's, which is invalid and caused some
fops to fail.

This patch filters out this case by ignoring config xattr == 0.

> Change-Id: Ied51c35b313ea8c3eeae27812f9bae61d3808e92
> Reviewed-on: http://review.gluster.org/13446
> BUG: 1293223
> Signed-off-by: Xavier Hernandez 

Change-Id: I42d06119d8f51c34ddb910380af7acd670f6244e
BUG: 1293224
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/13447
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Ashish Pandey 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

cluster/ec: Handle non-existent config xattr for non regular files

2016-01-20T07:03:57+00:00

Since we now try to get the 'trusted.ec.config' xattr for inodes of
type IA_INVAL (these inodes will be set to some valid type later),
if that inode corresponds to a non regular file, the xattr won't
exist and we will handle this as an error when it's not.

This patch solves the problem by only considering errors for inodes
that are already known to be regular files.

> Change-Id: Id72f314e209459236d75cf087fc51e09943756b4
> BUG: 1293223
> Signed-off-by: Xavier Hernandez 
> Reviewed-on: http://review.gluster.org/13238

Change-Id: I48a475ce889607e9b909f699b5d7f75b0657cb22
BUG: 1293224
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/13239
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri

cluster/ec: Get size and config for invalid inode

2016-01-13T12:27:52+00:00

Problem:
After creating an inode and before linking it
to inode table, if there is a request to setattr
for that file, it fails and leads to crash.
Before linking inode to inode table ia_type is IA_INVAL
which will casue have_size and have_config as zero.

Solution:
Check and get size and config if an inode is invalid

master-
http://review.gluster.org/#/c/13039/

Change-Id: I0c0e564940b1b9f351369a76ab14f6b4aa81f23b
BUG: 1293224
Signed-off-by: Ashish Pandey 
Reviewed-on: http://review.gluster.org/13066
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Pranith Kumar Karampuri

cluster/ec: Allow read fops to be processed in parallel

2015-11-25T03:03:17+00:00

Currently ec only sends a single read request at a time for a given
inode. Since reads do not interfere between them, this patch allows
multiple concurrent read requests to be sent in parallel.

This is a backport of these patches:

> Change-Id: If853430482a71767823f39ea70ff89797019d46b
> BUG: 1245689
> Signed-off-by: Xavier Hernandez 
> Reviewed-on: http://review.gluster.org/11742
> Tested-by: NetBSD Build System 
> Reviewed-by: Pranith Kumar Karampuri 
> Tested-by: Gluster Build System 
>
> Change-Id: I6042129f09082497b80782b5704a52c35c78f44d
> BUG: 1276031
> Signed-off-by: Xavier Hernandez 

Change-Id: I1b1146d1fd1828b12bfc566cd76e5ea110f8909b
BUG: 1251467
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/12447
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

cluster/ec: Mark internal fops appropriately

2015-11-20T11:17:00+00:00

1) Mark read fops in read-modify-write by EC as internal.
2) Handle uid/gid set/reset correctly

 >BUG: 1282761
 >Change-Id: I5c1ce0cd6213367eaead5fed33aa2397c4e46df7
 >Signed-off-by: Xavier Hernandez 
 >Reviewed-on: http://review.gluster.org/12599
 >Tested-by: Gluster Build System 
 >Tested-by: NetBSD Build System 
 >Reviewed-by: Pranith Kumar Karampuri 

BUG: 1283757
Change-Id: I9f039cf3ec6351525fb65381bad44d986595844f
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/12669
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System

cluster/ec: fix bug in update_good

2015-11-11T13:48:27+00:00

        Backport of http://review.gluster.com/12561

Problem:
Bricks that didn't participate in the fops are considered to be good. This is
happening two fold.

Examples:
Case-1:
1) 2+1 volume. 'd1' directory on Brick-0 is bad.
2) readdir takes locks and lock->good_mask is '7'
3) readdir does xattrop and fop->mask is '6'.
4) because fop->expected is '1' lock->good_mask remains '7'

Case-2:
1) when all the bricks are up, it does lock + xattrop before op and figures out
   all the bricks are good.
2) By the time second operation starts brick-0 is down. Now lock->good_mask
   will always have the '0' bit set as long as the operations are happening on it.
   because: "lock->good_mask &= ~fop->mask | fop->remaining" fop->mask doesn't
   have '0' th bit.
3) When it comes time to perform the final xattrop in update_size_version
   brick-0 comes online because of which it gives the same version to brick-0
   as well thinking it has participated in all the transactions till then, even
   when it didn't participate in the transactions.

Fix:
Case-1's fix: Update lock->good_mask in ec_prepare_update_cbk with latest
good/bad bricks
Case-2's fix: Consider non-participating brick as bad.

BUG: 1278744
Change-Id: I5c2b07005107f3c067bac69da3b37ff39688bd69
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/12562
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Xavier Hernandez