glusterfs.git/xlators/features/marker, branch v3.7.3

quota/marker: contribution with list_del can cause mem corruption

2015-07-21T09:35:34+00:00

This is a backport review.gluster.org/#/c/11706/

There is a possibility that contribution is removed twice from list
during unlink operation (with hard links) or during rename operation

Use list_del_init for a thread safe deltion of member from list

> Change-Id: Iff5e0c03cc8f0ed85da0db1739b84b695abf9ea6
> BUG: 1244109
> Signed-off-by: vmallika 

Change-Id: I79770c7e31a1d27e0fdfa6d1b0e28c8b03ba3329
BUG: 1244116
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11707
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

quota/marker: fix mem-leak in marker

2015-07-15T04:38:24+00:00

This is a backport of http://review.gluster.org/#/c/11617/

Free local in error paths

> Change-Id: I76f69e7d746af8eedea34354ff5a6bf50234e50e
> BUG: 1207735
> Signed-off-by: vmallika 

Change-Id: I0f87ee11970e7bf6f8c910d112fc988c2afd6eca
BUG: 1229282
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11620
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

quota/marker: use smaller stacksize in synctask for marker updation

2015-07-14T11:27:24+00:00

This is a backport of http://review.gluster.org/#/c/11499/

Default stacksize that synctask uses is 2M.
For marker we set it to 16k

Also move market xlator close to io-threads
to have smaller stack

> Change-Id: I8730132a6365cc9e242a3564a1e615d94ef2c651
> BUG: 1207735
> Signed-off-by: vmallika 

Change-Id: Id1cb6288a38d370956cc47aed5253ff95f04c966
BUG: 1229282
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11595
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

quota/marker: fix mem leak in marker

2015-07-14T05:20:33+00:00

This is a backport of http://review.gluster.org/#/c/11457/
Part of the fix is available in:
http://review.gluster.org/#/c/11527/

This patch optimizes the memory consumption.
create syntask txn only for linked inodes

Change-Id: Ia4410840025eb4f48a48c26b043862b4f8d5aa84
BUG: 1229282
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11593
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi

quota/marker: inspect file/dir invoked without having quota xattrs requested

2015-07-14T04:02:02+00:00

This is a backport of http://review.gluster.org/#/c/11616/

In a lookup and build ancestry quota xattrs are
not requested, it gives wrong assumption that
quota xattrs are missing and tries to do
healing process

> Change-Id: I7135101ec0edc72a6310dbb304227eaa3b16cb46
> BUG: 1207735
> Signed-off-by: vmallika 

Change-Id: I286d9634e8afeab691d8f4caa70865adfe8b184a
BUG: 1229282
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11619
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi

quota/marker: fix spurious failure afr-quota-xattr-mdata-heal.t

2015-07-13T06:53:27+00:00

This is a backport of http://review.gluster.org/#/c/11583

During quota-update process if inode info is present in size-xattr and
missing in contri-xattrs, then in function '_mq_get_metadata', we set
contri-size as zero (on error -2, which means usage info present, but
inode info missing).
With this we are calculating wrong delta and updating the same.

With this patch we are ignoring errors if inode info in xattrs are
missing

> Change-Id: I7940a0e299b8bb425b5b43746b1f13f775c7fb92
> BUG: 1241153
> Signed-off-by: vmallika 

Change-Id: Ie85fa84b5362ae179cc43402bd6a3a6d96a04b81
BUG: 1241831
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11614
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Krishnan Parthasarathi

quota/marker: set lk_owner when taking lock on parent in rename

2015-07-13T06:41:31+00:00

This is a backport of http://review.gluster.org/#/c/11561/

Before doing a rename operation marker takes inode lock on the file
parent,
here lk_owner is NULL and this can cause accounting problem with
multiple rename on the same directory

This patch fix the problem by setting lk_owner

> Change-Id: Ibb789e39b2833e425d0a5fca85282ff1465206cb
> BUG: 1240598
> Signed-off-by: vmallika 

Change-Id: Ibd3abaee2dd5d132906a79a518fbcedcdefc4552
BUG: 1241487
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11601
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

quota/marker: fix mem leak in marker

2015-07-08T05:34:55+00:00

This is a backport of http://review.gluster.org/#/c/11457/

Problem-1)
Now the marker accounting happens in background,
There is a possibility that before completing
create_xattr_txn another create txn can be initiated
for the same inode.
suppose if few 100 txns are initiated
before completion, this can block all synctask threads
waiting on a lock and this can also consume lot of memory
and can take more time to complete the background accounting
operation.

This patch improves the locking mechanism which
can improve the performance as well reduce memory
consumption

Problem-2)
For every lookup and for all inodes in readdirp
we were initiating a new txn, this can result
in more txn pending in synctask queue and
lead to huge memory consumption. inspect
file/dir should start a txn only if there
is some delta

Problem-3)
When there are multiple write operations on
same inode and all the synctask threads are busy.
As we are checking for updation_status
flag in background, all txn will be move to synctask queue.
This can increase the mem usage.

Only one txn for inode in a queue will be sufficient,
so check and set updation falg before moving txn to
background

> Change-Id: Ic42ce00f0a50ce51c7128ba68a1b6a0699a1cd14
> BUG: 1207735
> Signed-off-by: vmallika 

Change-Id: I52a05b99b19b97c79b69671120f53e05481f99cd
BUG: 1229282
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11527
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

quota: marker accounting goes bad with rename while writing a file

2015-07-02T11:26:44+00:00

This is a backport of http://review.gluster.org/#/c/11403/

> With below test-case, marker accounting becomes bad:
> 1) Create a volume with 1 brick
> 2) fuse mount
> 3) on one terminal write some data
>    dd if=/dev/zero of=f1 bs=1M count=500 oflag=sync
> 4) on another terminal execute below rename operation while the write is
> still in progress
>     for i in {1..50}; do
>         ii=`expr $i + 1`;
>         mv f$i f$ii;
>     done
>
> remove-xattr is already on while doing rename operation,
> we should not be doing again in background when reducing the
> parent size.
>
> Change-Id: I969a64bb559e2341315928b55b99203e9ddee3f2
> BUG: 1235195
> Signed-off-by: vmallika 
> Reviewed-on: http://review.gluster.org/11403
> Tested-by: NetBSD Build System 
> Reviewed-by: Raghavendra G 
> Tested-by: Gluster Build System 
> Tested-by: Raghavendra G 

Change-Id: Ic37c7f7bd74093ee7e155b305834dbc1fdd24b10
BUG: 1235990
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11425
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

features/marker: Cleanup loc in case of errors

2015-06-29T17:29:51+00:00

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

Missing loc_wipe() for error paths in mq_readdir_cbk() can
cause memory leaks. loc_wipe() is now done for both happy
and unhappy paths.

Change-Id: I882aa5dcca06e25b56a828767fb2b91a1efaf83b
BUG: 1228535
Signed-off-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/11098
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Shyamsundar Ranganathan