| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Change-Id: I012f78bac8ba82333628c59ef51d5e5f43d05ac7
BUG: 3158
Reviewed-on: http://review.gluster.com/329
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amar@gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I4dcad7ddf84bf98b4b7f4a0e407a418426674280
BUG: 2784
Reviewed-on: http://review.gluster.com/299
Reviewed-by: Vijay Bellur <vijay@gluster.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I503364c855d52605e301f4d3c205af6c9fc0e1df
BUG: 3366
Reviewed-on: http://review.gluster.com/380
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amar@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This is to fix to bug marker translator and quota translator cannot co-exist in same process.
Change-Id: I9f132b663f03641f4f2c7e168df8400adbc5570f
BUG: 3020
Reviewed-on: http://review.gluster.com/381
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amar@gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Id8a1dffa3c3200234ad154d1749278a2d7c7021b
BUG: 3502
Reviewed-on: http://review.gluster.com/336
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
that way, we can share the rebalance state with other peers
and can prevent confusion/conflicts when multiple rebalances
are done by different peers.
Change-Id: I24159e69332644718df7314f6f1da7fce9ff740e
BUG: 2112
Reviewed-on: http://review.gluster.com/343
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
|
|
| |
now 'replica' 'stripe' and 'transport' options can be given in any order
Change-Id: Ied992ae55e86028bd4f2d662ebd246db138d4548
BUG: 3521
Reviewed-on: http://review.gluster.com/370
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
|
|
| |
permissions in rename fop.
Change-Id: Id9ac1ecdd9753377c9eb24464f51dcbdc0cd2821
BUG: 3194
Reviewed-on: http://review.gluster.com/367
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Ib6730a708f008054fbd379889a0f6dd3b051b6ad
BUG: 3502
Reviewed-on: http://review.gluster.com/335
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, lookup triggers data self-heal but that is not the preferred way
of operating replicated volumes. We would like the data self heals to be
triggered in open instead.
Number of back-ground self-heals allowed is 16 and lookups block until
self-heal is completed. We want to prevent blocking in fops. We can not make
lookups independent of self-heal frames because when there are gfid conflicts
the decision of which file is correct is determined in self-heal phase.
So in afr, lookup self-heal is going to guarantee name space consistency
and open/fd fops will take responsibility for data consistency, these
are non blocking. The user needs to set the option cluster.data-self-heal
"open" for this behavior.
Change-Id: If9463cdb9ebac114708558ec13bbca0270acd659
BUG: 3503
Reviewed-on: http://review.gluster.com/334
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In configurations with a uid mapper, super user ID could be mapped
to a non-zero value. Hence making it configurable in access control
would be necessary for proper super-user semantics.
Change-Id: I51e8e0395680e9b96a99657a0af547659bd9affe
BUG: 2815
Reviewed-on: http://review.gluster.com/332
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a change in the way write transactions hold a lock
which optimizes the case of sequential writes from a single writer.
Lock phase of a transaction has two sub-phases. First is an attempt
to acquire locks in parallel by broadcasting non-blocking lock
requests. If lock aquistion fails on any server, then the held locks
are unlocked and revert to a blocking locked mode sequentially on
one server after another.
The change in this patch is to make the initial broadcasting lock
request attempt to acquire lock on the entire file. If this fails,
we revert back to the sequential "regional" blocking lock as before.
In the case where such an "eager" lock is granted in the non-blocking
phase, it gives rise to an opportunity for optimization. i.e, if
the next write transaction on the same FD arrives before the unlock
phase of the first transaction, it "takes over" the full file lock.
Similarly if yet another transaction arrives before the unlock phase
of the "optimized" transaction, that in turn "takes over" the lock
as well. The actual unlock now happens at the end of the last
"optimzed" transaction.
Any operation which arrives before the unlock phase of the previous
transaction is a potential candidate to become an "optimized"
transaction. In cases where the previous transaction had aquired
lock as a "regional" blocking lock, and the next transaction comes
in before its unlock phase, then it would not be an "optimized"
transaction.
Implied assumption
------------------
Since two or more transactions can now operate within the same
large lock, there is a possibility that overlapping transactions
can arrive at oppoosite orders on the servers. However in the
larger picture this is not possible as write-behind already
ensures that no two overlapping writes on an inode are in transit
at the same time. Overlapping writes across clients are not a
problem as they compete at locks anyways.
Theoretical benefits and potential harms
----------------------------------------
In case of a single writer: The benefits are large for sequential
writes. In the best case the entire file write can happen with just
one lock and unlock per server, provided writes are coming in fast
enough and getting pipelined by write-behind soon enough (which is
usually the case). If the writes are not coming in fast enough, then
the optimization "kicks in" for only those subsets of writes which
are close enough to get "piggybacked". For random writes the benefits
are the same as well. In any case the overall performance is better
than or equal to the performance without this optimization for a single
writer.
In case of multiple writers: When multiple writers are not writing
concurrently, there is no negative performance impact. When multiple
writers are writing concurrently to the same region, there is no
negative impact either, as they were previously getting arbitrated
at the locks translator too. In the case of multiple writers writing
to different regions concurrently, there will be an increased number
of "failovers" from failed parallel non-blocking to sequential blocking
regional locks. This above "worst case" has a simple workaround that
as soon as we detect > 1 open-fd-count in lookup xattr, we can disable
this optimization on those fds.
Beneficial side-effects
-----------------------
There is another similar optimization in AFR for changelogs which goes
by the name of "changelog-piggybacking". That works in a similar way where
pending flags get 'taken over' or 'piggybacked' by the next transaction
if its 'pre-op' phase kicks in before the 'post-op' phase of the
previous transaction. It has been observed that this changelog-piggybacking
optimization gives a saving of about ~55% savings of xattr calls hitting
the wire, measured across various types of network interfaces. The side
effect of this eager-lock optimization is that it gives an almost 100%
saving of xattr calls by making the optimistic-changelog work much more
efficiently as it gives a wider overlap of the xattr phases of two
consecutive transactions.
Change-Id: I41c02eb3b64c14c68ef66a344610ec3f024cd59d
BUG: 3409
Reviewed-on: http://review.gluster.com/240
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
| |
Now the key is logged with getxattr failure.
Change-Id: I96a9234cf138ae0922dc403e2fddcd4df0d89df8
BUG: 3283
Reviewed-on: http://review.gluster.com/373
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Glusterfs used to crash trying to dereference a NULL
pointer. Also, in mnt3_resolve_export_subdir, volume
name was prefixed to sub directory exported, resulting in
mount fail of sub directory. Fixed both issues.
Change-Id: I746f0c244b4cbf03033d73ac3e40518762d76385
BUG: 3481
Reviewed-on: http://review.gluster.com/323
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While inheriting the ACLs from a directory that has default ACLs, make sure
that the mode flags set by the application are saved. It is required to
inherit only the Read, Write and Execute permissions while leaving the others
viz. setuid, setgid and sticky bit untouched hence honouring the requests made
by the application during create operations (mknod, mkdir et al).
For a description of the problem, root cause and evaluation, refer:
http://bugs.gluster.com/show_bug.cgi?id=3522
Change-Id: I994077fb321a35d8254f0cc5a7de99a17ec40c47
BUG: 3522
Reviewed-on: http://review.gluster.com/368
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I559e6a0709b8064cfd54c693e289c741f9c4c4ab
BUG: 1570
Reviewed-on: http://review.gluster.com/319
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Kaushik BV <kaushikbv@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Intro Note
==========
The current code in hard fh resolution takes the first-match approach, i.e.
which ever dirent either matches the hash or matches the gfid first
is the one chosen as the result for the next step of fh resolution. In
the latter case, i.e., dirent matches the gfid, we the next step is to
conclude the fh resolution by returning the entry whose gfid matched.
In the former, i.e., the hash matches the dirent, we choose the hash-matching
dirent as the next directory to descend into, for searching the file to be
operated upon.
Problem
=======
When performing hard fh resolution, there can be a situation where:
o the hash of the primary entry,i.e. the entry we're looking for and the hash
of another sibling directory, match. Note the use of "sibling", meaning both
the primary entry and the hash matching one are in the same directory, i.e.,
their filehandle.hashcount will be same.
o the sibling directory is encountered first during the dir search.
Because of the current code described in "Intro", we'll end up descending into
the sibling directory even though the correct behaviour is to ignore this and
wait till we encounter the primary entry in the same parent directory.
Once we end up descending into this sibling directory, the directory depth
validation check fails. The check fails because it notices that the resolution
is attempting to open a directory that is deeper in the fs tree than the file
we're looking for. When this check fails, we return an ESTALE. So basically, a
false-positive results in an estale to Specsfs.
This is not a theoretical situation. Me and Avati saw this on specsfs test
where sfs created terabytes-sized file system for its tests. The number of
files was so huge in a single directory that the hashes of two entries ended up
colliding.
Change-Id: I4a6df11d326a67a507b1cd716c2c8e00b5a858a4
BUG: 3510
Reviewed-on: http://review.gluster.com/357
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Shehjar Tikoo <shehjart@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes ~200 such warnings, but leaves three categories untouched.
(1) Rpcgen code.
(2) Macros which set variables in the outer (calling function) scope.
(3) Variables which are set via function calls which may have side effects.
Change-Id: I6554555f78ed26134251504b038da7e94adacbcd
BUG: 2550
Reviewed-on: http://review.gluster.com/371
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
| |
without which, if a peer is added after volume of type 'stripe-replica'
is created, it won't be reflected in the newly added peer.
Change-Id: I77ee6aa3f33994bd4c6dbfefd853cc7e7491c1db
BUG: 3523
Reviewed-on: http://review.gluster.com/369
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
| |
so 'gluster peer probe' command doesn't hang till timeout (120s),
instead it will send the proper error msg to client.
Change-Id: I398fa16d526f869f1d27eeb57aeb7ee4451fbecd
BUG: 1852
Reviewed-on: http://review.gluster.com/342
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier:
step 1: copy the existing <xdr>.x files to /tmp
step 2: generate '.[ch]' files using 'rpcgen <xdr>.x'
step 3: check diff with the to the existing files, add only your part
of changes back to the original file. (ignore other changes).
step 4: there is another file to write wrapper functions to convert
structures to/from XDR buffers, update it with your new structure.
step 5: use these wrapper functions in the newly written procedures.
step 6: commit :-|
Now:
step 1: update (mostly adding only) the <xdr>.x file
step 2: run '<path-to-src>/extras/generate-xdr-files.sh <xdr>.x' command
step 3: implement rpc procedure to handle the request/response.
step 4: commit :-)
Change-Id: I219f9159fc980438c86e847c6b030be96e595ea2
BUG: 3488
Reviewed-on: http://review.gluster.com/341
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
| |
is a step towards reducing glusterfs memory footprint. should also
help a bit in overall performance.
Change-Id: I074d5813602b2c960d59562e792b3dc6e43d2f42
BUG: 3475
Reviewed-on: http://review.gluster.com/322
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The steps in normal data self heal:
1) take big lock by self-heal frame. Get the xattrs/stat to decide
source, sink information.
2) spawn loop frames which perform self-heal by taking small locks on
the file. Every time a new lock is taken and the old lock is released.
3) Before releasing the final small lock a big lock is taken by the
self-heal frame, and unlock on small-lock. Erasing of the pending xattrs
happen then the big unlock happen and that is the end of the data self-heal.
When a data self-heal is needed for a file and the fop
that triggers the self-heal is open with O_TRUNC. Fuse sends open then
an explicit truncate for this. Open triggers the self-heal but by the
time it tries to spawn the loops the file size is truncated to 0, so
no loops are formed.
These are the steps:
1) Take big lock by self-heal frame. Get the xattrs/stat to decide
source, sink information.
2) loop frames are not spawned. The big lock is not released.
3) One more big lock is taken by the same self-heal frame, Erasing of
the pending xattrs etc happen, now it does two big unlocks, but after
the first unlock, the information on which the locks were performed is
forgotten, so the next unlock becomes a no-op. So there is a stale big
lock on that file preventing further writes.
As a fix, if the loops are not spawned, use the previous big lock to
perform the rest of the operations needed in completing the data
self-heal. No need to have one more big lock.
Change-Id: Id03171269594e447b2b6d1331e362d83bd1e3430
BUG: 3506
Reviewed-on: http://review.gluster.com/339
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is brought in an effort to be nice to the system resources when
self-heal is in progress.
Change-Id: I123f1eb4d8000613a35c0117f0aa27f926f3a921
BUG: 3503
Reviewed-on: http://review.gluster.com/333
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
|
|
| |
created new files per operations, (or group of operations)
Change-Id: Iccb2a6a0cd9661bf940118344b2f7f723e23ab8b
BUG: 3158
Reviewed-on: http://review.gluster.com/281
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change contains,
- removal of the local cli lock used to serialize
cli ops to a glusterd.
- glusterd's state-machine can handle competing 'lockers' with
guaranteed progress.
- flush cluster lock on 'owner' disconnecting and as 'owner',
send unlock to all on first peer disconnect.
Change-Id: I25961436b0790b4196f2b3438b105c37279399ad
BUG: 3320
Reviewed-on: http://review.gluster.com/123
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
|
| |
Change-Id: I7b4e7c467b833bc5896808e6e1d1b1a0322c4fdb
BUG: 3483
Reviewed-on: http://review.gluster.com/318
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amar@gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The header of the ptr returned from mem-pool will now store the
mem-pool ptr it belongs to. mem_put will now take only the pointer
to be freed.
Also, changing MALLOC call to GF_CALLOC in mem_get when we run out
of entries in mem-pool. This also will have the header information
saved.
Change-Id: I3de182663a7f5b49c9e9425e9531775b70bdff67
BUG: 3390
Reviewed-on: http://review.gluster.com/205
Reviewed-by: Amar Tumballi <amar@gluster.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
| |
Change-Id: Ic117c6a3f9234a0181db1a106ef8a6574248f010
Reviewed-on: http://review.gluster.com/313
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amar@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use subprocess module instead of os.spawn* / ad-hoc fork/exec.
With this, we do now:
- close uneeded files in children
- watch childrens' stderr:
- have a thread which collects childrens' stderr into a ring buffer
(so that stderr pipe doesn't get stuffed)
- on command failure show stderr
- distinguish between rsync exit values, tolerate only partial errors
- if connection is broken to slave, show ssh/slave gsycd's stderr
Change-Id: Ia92f57b5bdfa47f8c44375c50cf279006a0bf69b
BUG: 2946
Reviewed-on: http://review.gluster.com/85
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Tested-by: Kaushik BV <kaushikbv@gluster.com>
Reviewed-by: Kaushik BV <kaushikbv@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I28de4cce140faf1b35ecdc5cbd408f21c9926341
BUG: 3231
Reviewed-on: http://review.gluster.com/96
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
|
|
| |
Some changes to profile info output.
Change-Id: I94a4bec1ca1c0670b3d9643f8321683b59c665aa
BUG: 3028
Reviewed-on: http://review.gluster.com/260
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amar@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Id8613f9641f748f996062342878070ba8fb27339
BUG: 2473
Reviewed-on: http://review.gluster.com/312
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Pranith Kumar Karampuri <pranithk@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ie. instead of writing out the fully expanded canonical URL like
ssh://root@192.168.3.4:gluster://127.0.0.1:bar
we just display
ssh://root@starship::bar
Change-Id: I2bd70650cbc9973d925f652bccb163d391e406c9
BUG: 2536
Reviewed-on: http://review.gluster.com/79
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Kaushik BV <kaushikbv@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I1649ed61b13b935d714ca024e6883f3903c5edeb
BUG: 3460
Reviewed-on: http://review.gluster.com/310
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amar@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I84580e297ba93a9a093c2e3432ea52e3c0db4a1a
BUG: 3467
Reviewed-on: http://review.gluster.com/307
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
|
|
| |
without which, quota would get confused about the total size
Change-Id: I0fb822ee67e3c1585f783ae35292fe71c47ee249
BUG: 3421
Reviewed-on: http://review.gluster.com/304
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Icc1e9dc039f1f2d7ee94c689779a715a69d373fa
BUG: 3389
Reviewed-on: http://review.gluster.com/296
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I84b4f7c9c2787334ce67e5c3e0534953b691c8e0
BUG: 3460
Reviewed-on: http://review.gluster.com/295
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Raghavendra Bhat <raghavendrabhat@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I66362a3087a635fb7b759d7836a1f6564a6a7fc9
BUG: 3456
Reviewed-on: http://review.gluster.com/294
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code is checking for priv->child_up[i], which can change while the fop
is in progress. Since pending[child][id-of-transaction] alone is enough
to tell if the child became stale or not, use just that.
Change-Id: I494bf02cca66f4fd41526195fafce86a202c6bd1
BUG: 3455
Reviewed-on: http://review.gluster.com/293
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Idce22a6266c354e327d5d717715d2e62533eec58
BUG: 3448
Reviewed-on: http://review.gluster.com/292
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I38ddfab200d59dd4c8e9f9dd964a98f3d7aa7ab7
BUG: 3389
Reviewed-on: http://review.gluster.com/289
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Ic227781760a5f6dbf8aad69a19f90e45d4aaec13
BUG: 3415
Reviewed-on: http://review.gluster.com/288
Reviewed-by: Krishnan Parthasarathi <kp@gluster.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I5aa6ee7509a8f730ca64e2f7bada56d502785a6c
BUG: 3415
Reviewed-on: http://review.gluster.com/287
Reviewed-by: Raghavendra Bhat <raghavendrabhat@gluster.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Ia2d89fd919b077232a37debc2aebe1bc72150856
BUG: 3432
Reviewed-on: http://review.gluster.com/285
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
|
| |
Change-Id: Ie026ebed98cf5ff75ae1a13437d29f67d0e0254a
BUG: 3448
Reviewed-on: http://review.gluster.com/286
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Raghavendra Bhat <raghavendrabhat@gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I8e5b8841705b161068bdb2ccd2ac119d6b250c88
BUG: 3415
Reviewed-on: http://review.gluster.com/284
Reviewed-by: Raghavendra Bhat <raghavendrabhat@gluster.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
|
|
|
|
|
|
|
|
|
| |
Change-Id: I861b3c4494735b0ba6e038cdc39c50b9866747a8
BUG: 3448
Reviewed-on: http://review.gluster.com/283
Reviewed-by: Raghavendra Bhat <raghavendrabhat@gluster.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I4704dfad655a79afb87ab275ba09413f785a97a4
BUG: 3446
Reviewed-on: http://review.gluster.com/280
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Raghavendra Bhat <raghavendrabhat@gluster.com>
|