glusterfs.git/xlators/cluster, branch v3.4.0alpha

cluster/dht: Correct min_free_disk behaviour

2013-02-04T16:43:50+00:00

Problem:
Files were being created in subvol which had less than
min_free_disk available even in the cases where other
subvols with more space were available.

Solution:
Changed the logic to look for subvol which has more
space available.
In cases where all the subvols have lesser than
Min_free_disk available , the one with max space and
atleast one inode is available.

Known Issue: Cannot ensure that first file that is
created right after min-free-value is crossed on a
brick will get created in other brick because disk
usage stat takes some time to update in glusterprocess.
Will fix that as part of another bug.

Change-Id: If3ae0bf5a44f8739ce35b3ee3f191009ddd44455
BUG: 858488
Signed-off-by: Raghavendra Talur 
Reviewed-on: http://review.gluster.org/4420
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/stripe: Mount issues with Stripe xlator

2013-02-03T23:29:59+00:00

Problem:
* 'CONNECTING' is taken as CHILD_UP.
* Sending notifications (default_notify()) for all the events individually
   while mounting.

Solution:
* Consider Child up only after the event CHILD_UP is received.
* Send a single notification for all the children's events only
   while mounting.

Change-Id: I1b7de127e12f5bfb8f80702dbdce02019e138bc8
BUG: 885072
Signed-off-by: Varun Shastry 
Reviewed-on: http://review.gluster.org/4356
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/dht: ignore EEXIST error in mkdir to avoid GFID mismatch

2013-02-03T20:14:19+00:00

In dht_mkdir_cbk, EEXIST error is treated like a true error. Because
of this the following sequence of events can happen, eventually
resulting in GFID mismatch and (and possibly leaked locks and hang,
in the presence of replicate.)

The issue exists when many clients concurrently attempt creation of
directory and subdirectory (e.g mkdir -p /mnt/gluster/dir1/subdir)

0. First mkdir happens by one client on the hashed subvolume. Only
   one client wins the race. Others racing mkdirs get EEXIST. Yet
   other "laggers" in the race encounter the just-created directory
   in lookup() on the hash dir.

1. At least one "lagger" lookup() notices that there are missing
   directories on other subvolumes (which the "winner" mkdir is yet
   to create), and starts off self-heal of the directory.

2. At least on some subvolumes, self-heal's mkdir wins the race
   against the "winner" mkdir and creates the directory first. This
   causes the "winner" mkdir to experience EEXIST error on those
   subvolumes.

3. On other subvolumes where "winner" mkdir won the race, self-heal
   experiences EEXIST error, but self-heal is properly translating
   that into a success (but mkdir code path is not -- which is the
   bug.)

4. Both mkdir and self-heal assign hash layouts to the just created
   directory. But self-heal distributes hash range across N (total)
   subvolumes, whereas mkdir distributes hash range across N - M
   (where M is the number of subvolumes where mkdir lost the race).
   Both the clients "cache" their respective layouts in the near
   future for all future creates inside them (evidence in logs)

5. During the creation of the subdirectory, two clients race again.
   Ideally winner performs mkdir() on the hashed subvolume and proceeds
   to create other dirs, loser experiences EEXIST error on the hashed
   subvolume and backs off. But in this case, because the two clients
   have different layout views of the parent directory (because of
   different hash splits and assignements), the hashed subvolumes for
   the new directory can end up being different. Therefore, both clients
   now win the race (they were never fighting against each other on a
   common server), assigning different GFIDs to the directory on their
   respective (different) subvolumes. Some of the remaining subvolumes
   get GFID1, others GFID2.

Conclusion/Fix:
   Making mkdir translate EEXIST error as success (just the way self-heal
   is already rightly doing) will bring back truth to the design claim
   that concurrent mkdir/self-heals perform deterministic + idempotent
   operations. This will prevent the differing "hash views" by different
   clients and thereby also avoid GFID mismatch by forcing all clients
   to have a "fair race", because the hashed subvolume for all will be
   the same (and thereby avoiding leaked locks and hangs.)

Change-Id: I84592fb9b8a3f739a07e2afb23b33758a0a9a157
BUG: 907072
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/4459
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

cluster/afr: added logging of changelog for split-brain in glustershd.log file

2013-02-03T19:48:01+00:00

Change-Id: Iaf119f839cb2113b8f8efb7bf7636d471b6541bf
BUG: 866440
Signed-off-by: Venkatesh Somyajula 
Reviewed-on: http://review.gluster.org/4385
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Jeff Darcy 
Tested-by: Gluster Build System

cluster/dht: stack wind with cookie

2013-02-01T01:18:03+00:00

Default_fops uses stack_wind_tail. It winds without creating the frame leading
into wrong subvol return in the cookie. To avoid the problem caused by the
same, we're getting the subvol by passing the cookie.

Change-Id: I51ee79b22c89e4fb0b89e9a0bc3ac96c5b469f8f
BUG: 893338
Signed-off-by: Varun Shastry 
Reviewed-on: http://review.gluster.org/4388
Reviewed-by: Jeff Darcy 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati 
Tested-by: Anand Avati

libglusterfs/syncop: do not hold ref on the fd in cbk

2013-01-31T07:40:37+00:00

* Do not do fd_ref in cbks of the fops which return a fd (such as
  open, opendir, create).

Change-Id: Ic2f5b234c5c09c258494f4fb5d600a64813823ad
BUG: 885008
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/4282
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Anand Avati

cluster/afr: if a subvolume is down wind the lock request to next

2013-01-29T20:50:55+00:00

When one of the subvolume is down, then lock request is not attempted
on that subvolume and move on to the next subvolume.

/* skip over children that are down */
                while ((child_index < priv->child_count)
                       && !local->child_up[child_index])
                        child_index++;

In the above case if there are 2 subvolumes and 2nd subvolume is down (subvolume
1 from afr's view), then after attempting lock on 1st child (i.e subvolume 0)
child index is calculated to be 1. But since the 2nd child is down child_index
is incremented to 2 as per the above logic and lock request is STACK_WINDed to
the child with child_index 2. Since there are only 2 children for afr the child
(i.e the xlator_t pointer) for child_index will be NULL. The process crashes
when it dereference the NULL xlator object.

Change-Id: Icd9b5ad28bac1b805e6e80d53c12d296526bedf5
BUG: 765564
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/4438
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/afr: wakeup delayed post op on fsync

2013-01-29T20:33:05+00:00

Change-Id: I5d84ef72615f9d71b4af210976e2449de6e02326
BUG: 888174
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/4446
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/afr: Change order of unwind, resume for writev

2013-01-29T20:29:51+00:00

Generally inode-write fops do transaction.unwind then
transaction.resume, but writev needs to make sure that
delayed post-op frame is placed in fdctx before unwind
happens. This prevents the race of flush doing the
changelog wakeup first in fuse thread and then this
writev placing its delayed post-op frame in fdctx.
This helps flush make sure all the delayed post-ops are
completed.

Change-Id: Ia78ca556f69cab3073c21172bb15f34ff8c3f4be
BUG: 888174
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/4428
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/afr: before checking lock_count of internal lock make sure its not

2013-01-28T08:20:46+00:00

             entrylk

when the expected lock count is equal to the attempted lock count, then before
deciding that lock is failed on all the nodes, make sure the lock type is
checked properly.

Change-Id: I1f362d54320cb6ec5654c5c69915c0f61c91d8c7
BUG: 765564
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/4436
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati