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

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

cluster/ec: update version and size on good bricks

2015-11-02T05:51:01+00:00

Problem: readdir/readdirp fops calls [f]xattrop with
fop->good which contain only one brick for these operations.
That causes xattrop to be failed as it requires at least
"minimum" number of brick.

Solution: Use lock->good_mask to call xattrop. lock->good_mask
contain all the good locked bricks on which the previous write
opearion was successfull.

Change-Id: If1b500391aa6fca6bd863702e030957b694ab499
BUG: 1272404
Signed-off-by: Ashish Pandey 
Reviewed-on: http://review.gluster.org/12419
Tested-by: NetBSD Build System 
Reviewed-by: Xavier Hernandez 
Tested-by: Xavier Hernandez 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-on: http://review.gluster.org/12440
Tested-by: Gluster Build System

cluster/ec: Implement gfid-hash read-policy

2015-10-29T11:52:49+00:00

Add a policy in ec to performs reads from same bricks as long as they
are good. Based on the gfid of the file/directory it determines the
bricks to be considered for reading.

 >Change-Id: Ic97b5c54c086a28b5e07a330a4fd448551b49376
 >BUG: 1261260
 >Signed-off-by: Pranith Kumar K 
 >Reviewed-on: http://review.gluster.org/12133
 >Tested-by: NetBSD Build System 
 >Tested-by: Gluster Build System 
 >Reviewed-by: Xavier Hernandez 

BUG: 1270705
Change-Id: Ibf0d21d7210125fa7aaa12b3f98bcdf7cd89ef02
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/12456
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System

cluster/ec: Fix tracking of good bricks

2015-08-14T09:02:21+00:00

The bitmask of good and bad bricks was kept in the context of the
corresponding inode or fd. This was problematic when an external
process (another client or the self-heal process) did heal the
bricks but no one changed the bitmaks of other clients.

This patch removes the bitmask stored in the context and calculates
which bricks are healthy after locking them and doing the initial
xattrop. After that, it's updated using the result of each fop.

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

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

cluster/ec: Minimize usage of EIO error

2015-08-08T15:36:57+00:00

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

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

cluster/ec: Handle race between unlock-timer, new lock

2015-07-23T16:36:46+00:00

Problem:
New lock could come at the time timer is on the way to unlock. This was leading
to crash in timer thread because thread executing new lock can free up the
timer_link->fop and then timer thread will try to access structures already
freed.

Fix:
If the timer event is fired, set lock->release to true and wait for unlock to
complete.

Thanks to Xavi and Bhaskar for helping in confirming that this race is the RC.
Thanks to Kritika for pointing out and explaining how Avati's patch can be used
to fix this bug.

> Change-Id: I45fa5470bbc1f03b5f3d133e26d1e0ab24303378
> BUG: 1243187
> Signed-off-by: Pranith Kumar K 
> Reviewed-on: http://review.gluster.org/11670
> Tested-by: Gluster Build System 
> Reviewed-by: Xavier Hernandez 
> Tested-by: NetBSD Build System 

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