glusterfs.git/xlators/features/shard, branch v4.0dev1

features/shard: Change default shard-block-size to 64MB

2017-09-14T03:23:15+00:00

Change-Id: I55fa87e07136cff10b0d725ee24dd3151016e64e
BUG: 1489823
Signed-off-by: Krutika Dhananjay 
Reviewed-on: https://review.gluster.org/18243
Reviewed-by: Pranith Kumar Karampuri 
Smoke: Gluster Build System 
Tested-by: Sunil Kumar Acharya 
CentOS-regression: Gluster Build System

features/shard: Increment counts in locks

2017-09-06T02:31:29+00:00

Problem:
Because create_count/eexist_count are incremented without locks, all the shards may not
be created because call_count will be lesser than what it needs to be. This can lead
to crash in shard_common_inode_write_do() because inode on which we want to do
fd_anonymous() is NULL

Fix:
Increment the counts in frame->lock

Change-Id: Ibc87dcb1021e9f4ac2929f662da07aa7662ab0d6
BUG: 1488354
Signed-off-by: Pranith Kumar K 
Reviewed-on: https://review.gluster.org/18203
Smoke: Gluster Build System 
Reviewed-by: Krutika Dhananjay 
CentOS-regression: Gluster Build System

features/shard: Return aggregated size in stbuf of LINK fop

2017-09-06T02:31:09+00:00

Change-Id: I42df7679d63fec9b4c03b8dbc66c5625f097fac0
BUG: 1488546
Signed-off-by: Krutika Dhananjay 
Reviewed-on: https://review.gluster.org/18209
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

features/shard: Remove ctx from LRU in shard_forget

2017-06-30T05:05:15+00:00

Problem:
There is a race when the following two commands are executed on the mount in
parallel from two different terminals on a sharded volume,
which leads to use-after-free.

Terminal-1:
while true; do dd if=/dev/zero of=file1 bs=1M count=4; done

Terminal-2:
while true; do cat file1 > /dev/null; done

In the normal case this is the life-cycle of a shard-inode
1) Shard is added to LRU when it is first looked-up
2) For every operation on the shard it is moved up in LRU
3) When "unlink of the shard"/"LRU limit is hit" happens it is removed from LRU

But we are seeing a race where the inode stays in Shard LRU even after it is
forgotten which leads to Use-after-free and then some memory-corruptions.

These are the steps:
1) Shard is added to LRU when it is first looked-up
2) For every operation on the shard it is moved up in LRU

Reader-handler                                    Truncate-handler
1) Reader handler needs shard-x to be read.     1) Truncate has just deleted shard-x
2) In shard_common_resolve_shards(), it does
   inode_resolve() and that leads to
   a hit in LRU, so it is going to call
__shard_update_shards_inode_list() to move the
   inode to top of LRU
						2) shard-x gets unlinked from the itable
						   and inode_forget(inode, 0) is called
						   to make sure the inode can be purged
						   upon last unref
3) when __shard_update_shards_inode_list() is
   called it finds that the inode is not in LRU
   so it adds it back to the LRU-list

Both these operations complete and call inode_unref(shard-x) which leads to the inode
getting freed and forgotten, even when it is in Shard LRU list. When more inodes are
added to LRU, use-after-free will happen and it leads to undefined behaviors.

Fix:
I see that the inode can be removed from LRU even by the protocol layers like gfapi/gNFS
when LRU limit is reached. So it is better to add a check in shard_forget() to remove itself
from LRU list if it exists.

BUG: 1466037
Change-Id: Ia79c0c5c9d5febc56c41ddb12b5daf03e5281638
Signed-off-by: Pranith Kumar K 
Reviewed-on: https://review.gluster.org/17644
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Krutika Dhananjay

features/shard: Handle offset in appending writes

2017-05-27T16:00:50+00:00

When a file is opened with append, all writes are appended at the end of file
irrespective of the offset given in the write syscall. This needs to be
considered in shard size update function and also for choosing which shard to
write to.

At the moment shard piggybacks on queuing from write-behind
xlator for ordering of the operations. So if write-behind is disabled and
two parallel appending-writes come both of which can increase the file size
beyond shard-size the file will be corrupted.

BUG: 1455301
Change-Id: I9007e6a39098ab0b5d5386367bd07eb5f89cb09e
Signed-off-by: Pranith Kumar K 
Reviewed-on: https://review.gluster.org/17387
Smoke: Gluster Build System 
Reviewed-by: Krutika Dhananjay 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

features/shard: Set size in inode ctx before size update for truncate too

2017-05-10T12:33:53+00:00

Change-Id: I7e984bb0f50c7d42764c0648e697d94d6c768dc7
BUG: 1448299
Signed-off-by: Krutika Dhananjay 
Reviewed-on: https://review.gluster.org/17184
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri 
Smoke: Gluster Build System

features/shard: Initialize local->fop in readv

2017-04-11T13:32:19+00:00

Change-Id: I9008ca9960df4821636501ae84f93a68f370c67f
BUG: 1440051
Signed-off-by: Krutika Dhananjay 
Reviewed-on: https://review.gluster.org/17014
NetBSD-regression: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Vijay Bellur

features/shard: Fix vm corruption upon fix-layout

2017-04-07T18:52:00+00:00

shard's writev implementation, as part of identifying
presence of participant shards that aren't in memory,
first sends an MKNOD on these shards, and upon EEXIST error,
looks up the shards before proceeding with the writes.

The VM corruption was caused when the following happened:
1. DHT had n subvolumes initially.
2. Upon add-brick + fix-layout, the layout of .shard changed
   although the existing shards under it were yet to be migrated
   to their new hashed subvolumes.
3. During this time, there were writes on the VM falling in regions
   of the file whose corresponding shards were already existing under
   .shard.
4. Sharding xl sent MKNOD on these shards, now creating them in their
   new hashed subvolumes although there already exist shard blocks for
   this region with valid data.
5. All subsequent writes were wound on these newly created copies.

The net outcome is that both copies of the shard didn't have the correct
data. This caused the affected VMs to be unbootable.

FIX:
For want of better alternatives in DHT, the fix changes shard fops to do
a LOOKUP before the MKNOD and upon EEXIST error, perform another lookup.

Change-Id: I8a2e97d91ba3275fbc7174a008c7234fa5295d36
BUG: 1440051
RCA'd-by: Raghavendra Gowdappa 
Reported-by: Mahdi Adnan 
Signed-off-by: Krutika Dhananjay 
Reviewed-on: https://review.gluster.org/17010
Smoke: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

shared: simplify and fix crash when we run out of memory

2017-04-07T03:48:06+00:00

Since mem_get0 can return NULL, local->op_ret is gonna
crash. Found by coverity. And since we only have ENOMEM
as potential error, we can also simplify the code by avoiding
using 'local' for that.

Change-Id: I778747b57f520b1a52347c0fc9f27efd7a7c5ca0
BUG: 789278
Signed-off-by: Michael Scherer 
Reviewed-on: https://review.gluster.org/16739
Smoke: Gluster Build System 
Tested-by: Michael Scherer 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-by: Krutika Dhananjay 
Reviewed-by: Pranith Kumar Karampuri

features/shard: Pass the correct iatt for cache invalidation

2017-03-30T06:15:51+00:00

This fixes a performance issue with shard which was causing
the translator to trigger unusually high number of lookups
for cache invalidation even when there was no modification to
the file.

In shard_common_stat_cbk(), it is local->prebuf that contains the
aggregated size and block count as opposed to buf which only holds the
attributes for the physical copy of base shard. Passing buf for
inode_ctx invalidation would always set refresh to true since the file
size in inode ctx contains the aggregated size and would never be same
as @buf->ia_size. This was leading to every write/read being preceded
by a lookup on the base shard even when the file underwent no
modification.

Change-Id: Ib0349291d2d01f3782d6d0bdd90c6db5e0609210
BUG: 1436739
Signed-off-by: Krutika Dhananjay 
Reviewed-on: https://review.gluster.org/16961
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri