glusterfs.git/xlators/storage, branch v3.5.3beta1

cluster/dht: Added code to capture races in dht-lookup path

2014-10-01T10:37:12+00:00

Change-Id: I9270d2d40ebd4b113ff961583dfda7754741f15b
BUG: 1129541
Signed-off-by: Venkatesh Somyajulu 
Reviewed-on: http://review.gluster.org/8430
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
(cherry picked from commit bb2d5f49b5684e6484af16a580870cfe104aecd2)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8731
Reviewed-by: Niels de Vos

storage/posix: Don't unlink .glusterfs-hardlink before linkto check

2014-10-01T10:35:14+00:00

BUG: 1129541
Change-Id: I90a10ac54123fbd8c7383ddcbd04e8879ae51232
Signed-off-by: Venkatesh Somyajulu 
Reviewed-on: http://review.gluster.org/8559
Tested-by: Gluster Build System 
Reviewed-by: N Balachandran 
Reviewed-by: Vijay Bellur 
(cherry picked from commit b23be2e7581c6aa295053dc8866cab841ae374b6)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8725
Reviewed-by: Niels de Vos

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

2014-09-17T15:34:54+00:00

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.

Change-Id: I3fee0d28de3c76197325536a9e30099d2413f079
BUG: 1129541
Signed-off-by: Venkatesh Somyajulu 
Reviewed-on: http://review.gluster.org/8345
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Vijay Bellur 
(cherry picked from commit 966997992bdbd5fffc632bf705678e287ed50bf7)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8719
Reviewed-by: Jeff Darcy

cluster/dht: Fix races to avoid deletion of linkto file

2014-09-17T15:34:33+00:00

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

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)

Change-Id: Ibf53671410d8d613b8e2e7e5d0ec30fc7dcc0298
BUG: 1129541
Signed-off-by: Venkatesh Somyajulu 
Reviewed-on: http://review.gluster.org/8231
Reviewed-by: Vijay Bellur 
Tested-by: Vijay Bellur 
(cherry picked from commit 74d92e322e3c9f4f70ddfbf9b0e2140922009658)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8717
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy

storage/posix: removing deleting entries in case of creation failures

2014-09-17T15:34:17+00:00

The code is not atomic enough to not to delete a dentry created by a
prallel dentry creation operation.

Change-Id: I9bd6d2aa9e7a1c0688c0a937b02a4b4f56d7aa3d
BUG: 1129527
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/8327
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
(cherry picked from commit 45fbf99cb669e891a84a8228cef27973f5e774bf)
Signed-off-by: Nithya Balachandran 
Reviewed-on: http://review.gluster.org/8716
Reviewed-by: Niels de Vos

protocol/server: send ENOENT instead of ESTALE for older clients

2014-06-20T09:45:54+00:00

Modify protocol/server and storage/posix to send ENOENT to older clients
instead of ESTALE

http://goo.gl/t83hmL

Change-Id: Ie63e91e73e33769ce9dc3d964938cfd6eb4c4be5
BUG: 1109832
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/8080
Reviewed-by: Raghavendra Bhat 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

features/marker-quota: more stringent error handling in rename.

2014-05-11T02:36:10+00:00

If an error occurs and op_errno is not set to non-zero value, we can
end up in loosing a frame resulting in a hung syscall. This patch
adds code setting op_errno appropriately in storage/posix and
makes marker to set err to a default non-zero value in case of
op_errno being zero.

Change-Id: Idc2c3e843b932709a69b32ba67deb284547168f2
BUG: 833586
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/6913
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

posix: if brick-uid or brick-gid is not specified, do not set

2014-05-09T14:36:02+00:00

Current code would set owner uid/gid explicitly to 0/0 on start
even if none was specified. Fix it.

Cherry picked from commit 8bdc329:
> Change-Id: I72dec9e79c51bd1eb3af5334c42b7c23b01d0258
> BUG: 1040275
> Signed-off-by: Anand Avati 
> Reviewed-on: http://review.gluster.org/6476
> Tested-by: Gluster Build System 
> Tested-by: Lukáš Bezdička 
> Reviewed-by: Krishnan Parthasarathi 
> Reviewed-by: Vijay Bellur 

Change-Id: Ie0396c1a4e6e0979ea9c855d33db963544a75c42
BUG: 1095971
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/7720
Tested-by: Gluster Build System

storage/posix: lgetxattr called with invalid keys on the bricks

2014-05-05T20:35:14+00:00

More invalid keys have crept in since this was fixed. We need a better
strategy for avoiding this than the current noticed-in-an-strace..

Cleaned tabs while I'm at it.

Change-Id: I0d5d3dd925cc626d06768b022ea0a572a9ea7e06
BUG: 765202
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/7004
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

storage/posix: do not dereference gfid symlinks before posix_handle_mkdir_hashes()

2014-05-05T13:38:03+00:00

Whenever a new directory is created, its corresponding gfid file must
also be created. This was done first calling MAKE_HANDLE_PATH() to get
the path of the gfid file, then calling posix_handle_mkdir_hashes() to
create the parent directories of the gfid, and finally creating the
soft-link.

In normal circumstances, the gfid we want to create won't exist and
MAKE_HANDLE_PATH() will return a simple path to the new gfid. However if
the volume is damaged and a self-heal is running, it is possible that we
try to create an already existing gfid. In this case, MAKE_HANDLE_PATH()
will return a path to the directory instead of the path to the gfid.

To solve this problem, every time a path to a gfid is needed, a call to
MAKE_HANDLE_ABSPATH() is made instead of the call to MAKE_HANDLE_PATH().

BUG: 859581
Change-Id: I84405bf04562e647fc02445f45358e9451f9b479
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/6736
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Raghavendra Bhat 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Niels de Vos