glusterfs.git/xlators/cluster/dht/src/dht-common.h, branch v3.4.7beta2

cluster/dht: Rename should not fail post hardlink creation

2014-10-20T14:56:00+00:00

In the rename path, we wind the creation of newname hardlink and
linkto file in dst hashed a the same time. If the linkto creation
fails, but the link creation succeeds, we enter the failure code
and cleanup the created newname hardlink.

In the interim if another client looks up newname and finds it as
a hardlink from FUSE, it could send an unlink for oldname instead
of a rename. This combined with the above cleanup code could end
up losing all the files copies, and thereby losing data.

This fix separates these steps into 2 parts, creating the linkto
first and then the link file, so that post link file creation no
failures would cleanup the newname file. If linkto fails then link
is not attempted, thereby not polluting the name space with
newname.

Change-Id: I61da8e906060da16a31ea1076eec2f01fd617f44
BUG: 1139998
Signed-off-by: Shyam 
Reviewed-on: http://review.gluster.org/8570
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8683
Reviewed-by: Kaleb KEITHLEY

cluster/dht: synchronize rename and file-migration

2014-10-20T14:55:36+00:00

Change-Id: I4f243c946f76d440680b651235f925e3d0ebf0fd
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8523
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
BUG: 1139998
Reviewed-on: http://review.gluster.org/8681
Reviewed-by: Kaleb KEITHLEY

cluster/dht: introduce locking api.

2014-10-20T14:55:11+00:00

Change-Id: I41389ba91951d3e63e617aa32cd0bee848261c72
BUG: 1139998
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8521
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8679
Reviewed-by: Kaleb KEITHLEY

cluster/dht: Prevent dht_access from going into a loop.

2014-10-20T14:54:49+00:00

If access fails with ENOTCONN, do not wind to same subvol.
We wind to first-up-subvol if access fails with ENOTCONN.
In few cases, if dht has only 1 subvolume, and access fails with
ENOTCONN, we go into a infinite loop of winding to same subvol

The fix is to check if we previously wound to same subvol, and
fail if first-up-subvol is same.

Change-Id: Ib5d3ce7d33e8ea09147905a7df1ed280874fa549
BUG: 1139996
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.org/5319
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati 
Reviewed-on: http://review.gluster.org/8677
Reviewed-by: N Balachandran 
Reviewed-by: Kaleb KEITHLEY

cluster/dht: Fix races to avoid deletion of linkto

2014-10-20T14:53:56+00:00

 file

Explanation of Race between rebalance processes:
https://bugzilla.redhat.com/show_bug.cgi?id=1110694#c4

scenario-1:
===========

STATE 1:                          BRICK-1
only one brick                   Cached File
in the system

STATE 2:
Add brick-2                       BRICK-1                BRICK-2

STATE 3:                                       Lookup of File on brick-2
                                               by this node's rebalance
                                               will fail because hashed
                                               file is not created yet.
                                               So dht_lookup_everywhere is
                                               about to get called.

STATE 4:                         As part of lookup
                                 link file at brick-2
                                 will be created.

STATE 5:                         getxattr to check that
                                 cached file belongs to
                                 this node is done

STATE 6:

                                            dht_lookup_everywhere_cbk detects
                                            the link created by rebalance-1.
                                            It will unlink it.

STATE 7:                        getxattr at the link
                                file with "pathinfo" key
                                will be called will fail
                                as the link file is deleted
                                by rebalance on node-2

Fix:
So in the STATE 6, we should avoid the deletion of link file. Every time
dht_lookup_everywhere gets called, lookup will be performed on all the nodes.
So to avoid STATE 6, if linkto file is found, it is not deleted until valid
case is found in dht_lookup_everywhere_done.

Case 1: if linkto file points to cached node, and cached file exists,
        uwind with success.

Case 2: if linkto does not point to current cached node, and cached file
        exists:
        a) Unlink stale link file
        b) Create new link file

Case 3: Only linkto file exists:
        Delete linkto file

Case 4: Only cached file
        Create link file (Handled event without patch)

Case 5: Neither cached nor hashed file is present
        Return with ENOENT (handled even without patch)

Reviewed-on: http://review.gluster.org/8231

******************************************************************************

scenario-2:
===========
cluster/dht: Modified logic of linkto file deletion on non-hashed

Currently whenever dht_lookup_everywhere gets called, if in
dht_lookup_everywhere_cbk, a linkto file is found on non-hashed
subvolume, file is unlinked. But there are cases when this file
is under migration. Under such condition, we should avoid deletion
of file.

When  some other rebalance process changes the layout of parent
such that dst_file (w.r.t. migration) falls on non-hashed node,
then may be lookup could have found it as linkto file but just
before unlink, file  is under migration or already migrated
In such cased unlink can be avoided.

Race:
-------
If we have two bricks (brick-1 and brick-2) with initial file "a"
under BaseDir which is hashed as well as cached on (brick-1).

Assume "a"  hashing gives 44.

                              Brick-1              Brick-2

Initial Setup:               BaseDir/a             BaseDir
                             [1-50]                [51-100]

Now add new-brick Brick-3.

1. Rebalance-1 on node Node-1 (Brick-1 node) will reset
the BaseDir Layout.

2. After that it will perform
a)  Create linkto file on  new-hashed (brick-2)
b)  Perform file migration.

1.Rebalance-1 Fixes the base-layout:
                 Brick-1             Brick-2           Brick-3
                 ---------         ----------         ------------
                 BaseDir/a            BaseDir           BaseDir
                  [1-33]              [34-66]           [67-100]

2. Only a) is     BaseDir/a          BaseDir/a(linkto)   BaseDir
   performed                         Create linktofile

Now rebalance 2 on node-2 jumped in and it will perform
step 1 and 2-a.

After (rebal-2, step-1), it changes the layout of the BaseDir.
                    BaseDir/a     BaseDir/a(link)    BaseDir
                    [67-100]           [1-33]        [34-66]

For  (rebale-2, step-2), It will perform lookup at Brick-3 as w.r.t new
layout 44 falls for brick-3. But lookup will fail.
So  dht_lookup_everywhere gets called.

NOTE: On brick-2 by rebalance-1, a linkto file was created.

Currently that linkto files gets deleted by rebalance-2 lookup as it
is considered as stale linkto file.  But  with patch if rebalance is
already in progress or rebalance is over,  linkto file will not be
unlinked. If rebalance is in progress fd will be  open and if rebalance
is over then linkto file wont be set.

Reviewed-on: http://review.gluster.org/8345

*******************************************************************************

scenario-3:
===========

cluster/dht: Added keys in dht_lookup_everywhere_done

Case where both cached  (C1)  and hashed file are found,
but hash does not point to above cached node (C1), then
dont unlink if either fd-is-open on hashed or
linkto-xattr is not found.

Reviewed-on: http://review.gluster.org/8429
BUG: 1139995
Signed-off-by: Venkatesh Somyajulu 
Change-Id: I86d0a21d4c0501c45d837101ced4f96d6fedc5b9
Signed-off-by: Venkatesh Somyajulu 
Tested-by: Gluster Build System 
Reviewed-by: susant palai 
Reviewed-by: Raghavendra G 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8674
Reviewed-by: Kaleb KEITHLEY

dht: fix rename race

2014-10-20T14:52:48+00:00

If two clients try to rename the same file at the same time, we
sometimes end up with *no file at all* in either the old or new
location.  That's kind of bad.  The culprit seems to be some overly
aggressive cleanup code.  AFAICT, based on today's study of the code,
the intent of the changed section is to remove any linkfile we might
have created before the actual rename.  However, what we're removing
might not be our extra link.  If we're racing with another client that's
also doing a rename, it might be the only remaining link to the user's
data.  The solution, which is good enough to pass this test but almost
certainly still not complete, is to be more selective about when we do
this unlink.  Now, we only do it if we know that, at some point, we did
in fact create the link without error (notably ENOENT on the source or
EEXIST on the destination) ourselves.

Change-Id: I8d8cce150b6f8b372c9fb813c90be58d69f8eb7b
BUG: 1139988
Signed-off-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/8269
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8672
Reviewed-by: Raghavendra G 
Reviewed-by: Kaleb KEITHLEY

DHT/readdirp: Directory not shown/healed on mount point if exists on single brick(non first up subvolume).

2014-10-20T14:52:14+00:00

Problem: If snapshot is taken, when mkdir has succeeded only on
hashed_subvolume, then after restoring snapshot the directory
is not shown on mount point.

Why:    dht_readdirp takes only those directory entries in to
account, which are present on first_up_subvolume. Hence, if the
"hashed subvolume" is not same as first_up_subvolume, it wont be listed
on mount point and also not healed.

Solution:
Case 1: (Rebalance not running)If hashed subvolume is NULL or down then
filter in first_up_subvolume. Other wise the corresponding hashed subvolume
will take care of the directory entry.

Case 2: If readdirp_optimize option is turned on then read from first_up_subvol

Change-Id: Idaad28f1c9f688dbfb1a8a3ab8b244510c02365e
BUG: 1139986
Signed-off-by: Susant Palai 
Reviewed-on: http://review.gluster.org/7599
Reviewed-by: Raghavendra G 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8671
Reviewed-by: Kaleb KEITHLEY 
Tested-by: Kaleb KEITHLEY

Revert "core: fix errno for non-existent GFID"

2013-12-24T11:31:53+00:00

This reverts commit 837422858c2e4ab447879a4141361fd382645406

Change-Id: I0909f26ce088454bb14b3694b489c672286a4ae6
Reviewed-on: http://review.gluster.org/6575
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

cluster/dht: Del GF_READDIR_SKIP_DIRS key from dict for first_up

2013-12-14T13:28:32+00:00

Currently, we sent GF_READDIR_SKIP_DIRS for all subvolumes if
first_subvol != first_up_subvolume.

Also first_up_subvolume can change with-in the life of a call and
cbk. Saving the first_up_subvol in dht_local for checks.

Back porting fix http://review.gluster.org/5577

BUG: 996474
Change-Id: I67b5bbe781e12812557b569b7d0a0beba4224159
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.org/6468
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

core: fix errno for non-existent GFID

2013-11-26T19:49:05+00:00

When clients refer to a GFID which does not exist, the errno to
be returned in ESTALE (and not ENOENT). Even though ENOENT might
look "proper" most of the time, as the application eventually expects
ENOENT even if a parent directory does not exist, not returning
ESTALE results in resolvers (FUSE and GFAPI) to not retry resolution
in uncached mode. This can result in spurious ENOENTs during
concurrent path modification operations.

Change-Id: I7a06ea6d6a191739f2e9c6e333a1969615e05936
BUG: 1032894
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/6322
Tested-by: Gluster Build System