glusterfs.git/xlators/cluster/dht/src/dht-layout.c, branch v3.5.8

core: fix errno for non-existent GFID

2013-11-26T18:29:23+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/6318
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Brian Foster 
Reviewed-by: Vijay Bellur

Revert "cluster/dht: Return success in dht_discover if layout issues"

2013-09-25T06:48:04+00:00

This reverts commit a3e593f9f17cb1e68db97bb5a0d8074793a33964 which
was bought into fix dht_layout_anomalies error handling.

We still see applications error'ing out due to graph switches.

To fix the above issue -

We cannot heal in dht_discover, as it is a gfid based lookup, and not
path based. So, returning error here would lead to app's to see failure.

Also, update the layout in inode_ctx even if it has anomalies. Let
subsequent heals fix the issue.

Conflicts:
	xlators/cluster/dht/src/dht-common.c

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

cluster/dht: Fix anomaly check

2013-09-23T18:40:33+00:00

We were wrongly detecting holes/overlaps for already accounted
errors. Additionally, sort should also handle zero'ed out layout

Change-Id: Ic3d13e1d735b914f9acc01fe919bc90656baea48
BUG: 1003851
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.org/5762
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Anand Avati

cluster/dht: Return success in dht_discover if layout issues

2013-06-03T08:06:36+00:00

We cannot heal in dht_discover, as it is a gfid based lookup, and not
path based. So, returning error here would lead to app's to see failure.

Also, update the layout in inode_ctx even if it has anomalies. Let
subsequent heals fix the issue.

Change-Id: I2358aadacf9a24e20a22ab0a6055c38c5eb6485c
BUG: 960348
Original-author: shishir gowda 
Signed-off-by: shishir gowda 
Signed-off-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/4959
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/distribute: Ignore non-participating subvols for layout checks

2013-04-09T19:49:40+00:00

When subvols-per-directory is < available subvols, then there are layouts
which are not populated. This leads to incorrect identification of holes or
overlaps. We need to ignore layouts, which have err == 0, and start == stop.
In the current scenario (start == stop == 0).

Additionally, in layout-merge, treat missing xattrs as err = 0. In case of
missing layouts, anomalies will reset them.

For any other valid subvoles, err != 0 in case of layouts being zeroed out.

Also reverted back dht_selfheal_dir_xattr, which does layout calculation only
on subvols which have errors.

Change-Id: I9f57062722c9e8a26285e10675c31a78921115a1
BUG: 921408
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.org/4668
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Jeff Darcy

dht: make DHT xattr names configurable

2013-03-21T22:04:31+00:00

This is necessary to support "DHT over DHT" configurations, so that the
upper and lower instances of DHT don't step all over each other.  Why
would we even consider such a thing?  Because it gives us the ability to
do data tiering and rack-aware placement, either by themselves or as
complements to other functionality such as erasure codes or
deduplication which save space but cost performance.  By setting up the
top-level DHT to place data into one of several lower-level DHT pools
based on policy instead of pure elastic hashing, we get better
performance for 90% of accesses and better storage efficiency for 90% of
data, all for relatively low effort.

Change-Id: I72e65c29edfc80babf39f7a2a00090f4588c4070
BUG: 924265
Signed-off-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/4694
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

distribute: add hash-name-regex option

2013-02-19T04:50:48+00:00

This is to support the common "write to temp file then rename" idiom. In our
case this causes us to create a linkfile during the rename in (N-1)/N cases,
with a significant impact on performance e.g. for UFO which uses this idiom.
This patch allows the user to specify up to two regular expressions that
separate the permanent and transient parts of a temp-file name:

    rsync-hash-regex reimplements the existing RSYNC_FRIENDLY_NAME
    pattern where the temporary name for EXAMPLE is .EXAMPLE.suffix

    extra-hash-regex can be used for a second pattern, active concurrently,
    and can include alternatives via the POSIX extended-regex syntax

Change-Id: Ic1a6ed19324bc31fefe91ee34b8478877a9c5d2c
BUG: 912564
Signed-off-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/4116
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

dht: better layout-optimization algorithm

2013-02-07T16:27:40+00:00

This method deals with the case where swapping might gain a bigger overlap
for the xlator currently under consideration, but sacrifices even more from
the xlator we're swapping with. For example:

A = 0x00000000 - 0x44444443 (new 0x00000000 - 0x55555554)
B = 0x44444444 - 0x77777776 (new 0x55555555 - 0xaaaaaaa9)
C = 0x77777777 - 0xffffffff (new 0xaaaaaaaa - 0xffffffff)

Here, the new range for B has a bigger overlap with the old C than with the
old B (0x33333333 vs. 0x22222222 to be precise) so looking only at that
might lead us to swap. However, such a swap turns the new C's overlap from
0x55555556 (vs. old C) to *zero* (vs. old B).  In other words, we've gained
0x11111111 for B but lost 0x55555556 for C, so it's a bad idea.

The new algorithm accounts for all effects of the swap, so it not only avoids
bad swaps but can make some good ones that would have been missed previously.
For example, if swapping a range X with a later range Y would not increase the
overlap for X we would previously have skipped it even if the swap would
increase Y's overlap without affecting X's.  This is the normal case when we're
adding a new brick (which initially has zero overlap with any old range) so
finding more good swaps is probably even more important than avoiding bad ones.

Also, the logic in dht_overlap_calc was completely broken before, causing
integer overflows instead of providing correct values, so no matter what
higher-level algorithm was in place the GIGO effect would have resulted in
bad decisions.

Change-Id: If61ed513cfcb931916c6b51da293e3efbaaf385f
BUG: 853258
Signed-off-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/3908
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cluster/distribute: re-set layouts to prevent overlaps

2012-12-12T00:05:50+00:00

When subvols-per-directory option is used, with bricks addition/removal
the layouts might get distributed to other subvols, which were not part
of the layout before. We need to clean up layouts on old subvolumes, to
prevent overlaps.

Also, we need to make sure if layout-cnt is never less
than subvolume-cnt.

Change-Id: I00994a092ca0c99aedcc41bd9412d43460f88a04
BUG: 884455
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.org/4281
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

fix memory leaks

2012-12-04T20:14:28+00:00

* write-behind: free the inode context in wb_forget
* distribute: in readdirp callback put the allocated context to the inode
* distribute: check if the layout is NULL before accessing it in layout_unref

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