| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To avoid inconsistent directory listings, a full self-heal
cannot happen on a directory until all its contents have
been healed. This is controlled by a manual command using
getfattr recursively and in post-order.
While navigating the directories, sometimes an (f)stat fop
can be sent. This fop caused a full self-heal of the directory.
This patch makes that (f)stat only initiates a partial self-heal.
This is a backport of http://review.gluster.org/9117/
Change-Id: I0a92bda8f4f9e43c1acbceab2d7926944a8a4d9a
BUG: 1159498
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/9118
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This is a backport of http://review.gluster.org/8990/
Change-Id: I35e11d83c318210d44b918e847cf13db35b01510
BUG: 1158088
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/8992
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: File ownership is not being preserved for root in geo-rep
mountbroker setup.
Analysis and Cause:
Entry creations for geo-rep is overloaded in ga_setxattr.
It happens in two phase, entry creation followed by setattr
to preserve ownership as in master.
If uid and gid of file being synced is root, setattr was
not being sent down. Since, the file creation happens with
non-root user in mountborker geo-rep setup, if setattr is
not done explicitly, file ownership is not preserved for root.
Solution:
Always pass setattr down in overloaded ga_setxattr.
BUG: 1159213
Change-Id: I0a6ef16333190b069e2ae326721d2b983f6a1a44
Reviewed-on: http://review.gluster.org/9051
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/9083
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Tested-by: Venky Shankar <vshankar@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Valid SETATTR entries are missing in changelog when more
than one metadata operation happen on same inode within
changelog roll-over time.
Cause: Metadata entries with fop num being GF_FOP_NULL are logged
in changelog which is of no use. Since slice version
checking is done for metadata entries to avoid logging of
subsequent entries of same inode falling into same
changelog, if the entry with GF_FOP_NULL is logged first,
subsequent valid ones will be missed.
Solution: Have a boundary condition to log only those fops whose fop
number falls between GF_FOP_NULL and GF_FOP_MAXVALUE.
BUG: 1159213
Change-Id: I128cad323afba7d33f48df1ee5e78cb829536211
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/8964
Reviewed-by: Aravinda VK <avishwan@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Tested-by: Venky Shankar <vshankar@redhat.com>
Reviewed-on: http://review.gluster.org/9028
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: glusterd crashes in non-originator slave node during geo-rep
create push-pem.
Cause: In glusterd_op_copy_file, the value of the key "common_pem_contents"
is freed explicitly even after dict_set is successful when it is
taken cared by dict_free.
Solution: Free only in failure cases before dict_set.
BUG: 1159210
Change-Id: I726f923915fc24de6588469c27f2cc996c20c59d
Reviewed-On: http://review.gluster.org/9018/
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/9026
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Tested-by: Venky Shankar <vshankar@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PROBLEM:
Geo-rep misses few a files to sync when I/O happenned during
geo-rep start.
ANALYSES:
To use the available changelogs to handle deletes/renames,
'xsync upper limit' is introduced which limits the xsync
crawl till the changelog register time. But there is a
small time interval between the changelog register time and
the time changelog actually enabled. If there is I/O between
this interval, it will not be synced through xsync as it is
beyond changelog register time and not through changelog also
as changelog is not actually enabled.
SOLUTION:
Enable changelog and marker during geo-rep create instead
of geo-rep start so that entries are captured in changelog
and above said interval is nullified.
BUG: 1159205
Change-Id: If5203eb1cfcbde3999f97a5f1a6a1af4875ac358
Reviewed-on: http://review.gluster.org/8650
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/9023
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Tested-by: Venky Shankar <vshankar@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When geo-rep is in paused state and a node in a cluster
is rebooted, the geo-rep status goes to "faulty (Paused)"
and no worker processes are started on that node yet. In
this state, when geo-rep is resumed, there is a race in
updating status file between glusterd and gsyncd itself
as geo-rep is resumed first and then status is updated.
glusterd tries to update to previous state and gsyncd
tries to update it to "Initializing...(Paused)" on
restart as it was paused previously. If gsyncd on restart
wins, the state is always paused but the process is not
acutally paused. So the solution is glusterd to update
the status file and then resume.
BUG: 1159195
Change-Id: I4c06f42226db98f5a3c49b90f31ecf6cf2b6d0cb
Reviewed-on: http://review.gluster.org/8911
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/9021
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Tested-by: Venky Shankar <vshankar@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of: http://review.gluster.org/#/c/9020
Take entrylks in xlator domain before doing post-op (undo-pending) in
entry self-heal. This is to prevent a parallel name self-heal on
an entry under @fd->inode from reading pending xattrs while it is
being modified by SHD after entry sh below, given that
name self-heal takes locks ONLY in xlator domain and is free to read
pending changelog in the absence of the following locking.
Change-Id: I0bc92978efc0741d6e3f2439540d008e31472313
BUG: 1136821
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
Reviewed-on: http://review.gluster.org/9030
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Tested-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Tested-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I691635e60aba72642c3c79d7da472884f1228301
BUG: 1158791
Reviewed-on: http://review.gluster.org/9008
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
correct before doing any fop
The following operations might lead to problems:
* Create a file on the glusterfs mount point
* Create a snapshot (say "snap1")
* Access the contents of the snapshot
* Delete the file from the mount point
* Delete the snapshot "snap1"
* Create a new snapshot "snap1"
Now accessing the new snapshot "snap1" gives problems. Because the inode and
dentry created for snap1 would not be deleted upon the deletion of the snapshot
(as deletion of snapshot is a gluster cli operation, not a fop). So next time
upon creation of a new snap with same name, the previous inode and dentry itself
will be used. But the inode context contains old information about the glfs_t
instance and the handle in the gfapi world. Directly accessing them without
proper check leads to ENOTCONN errors. Thus the glfs_t instance should be
checked before accessing. If its wrong, then right instance should be obtained
by doing the lookup.
Change-Id: I975245b8f6b7fea0a90eb5e36e8149d12457ac10
BUG: 1158791
Reviewed-on: http://review.gluster.org/9007
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Tested-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On non Linux systems, we check that seekdir() succeeds and we return
EINVAL if it does not. We need this to avoid infinite loops if some
other component in GlusterFS makes an invalid seekdir() usage. This
was introduced in this change: http://review.gluster.org/#/c/8760/
But seekdir() also fails when using the offset returned for the
last entry, and this is expected behavior. As a result, the seekdir()
test produces a spurious EINVAL when reaching end of directory. That
error is not propagated to calling process, but it may harm internal
GlusterFS processing. At least it produce a spurious error message
in brick's log.
We fix the problem by remembering the last entry offset in fd private
data. When a new posix_readdir() invocation requests that offset,
we avoid returning EINVAL.
Backport of I4e67a2ea46538aae63eea663dd4aa33b16ad24c7
BUG: 1138897
Change-Id: I4e98294d157f67ae1a1f0ece1562c77d1219da40
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/8933
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Change-Id: I2bd34f063d6bf1835d5ae57a8e9aa03f3ec3deb3
BUG: 1156405
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/8976
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some issues in ec xlator made that rebalance didn't complete
successfully and generated some warnings and errors in the
log. The most critical error was a race condition that caused
false corruption detection when two specific operations were
executed sequentially and they shared the same lock.
This explains the problem:
1. A setxattr is issued.
2. setxattr: ec locks the inode before updating the xattr.
3. setxattr: The xattr is updated.
4. setxattr: Upper xlator is notified that the operation completed.
5. setxattr: A background task is initiated to update the version
of the file.
6. A stat is issued on the same file.
7. stat: Since the lock is already acquired, it's reused.
8. stat: A lookup is issued to determine version and size
information of the file.
At this point, operations 5 and 8 can interfere. This can make that
lookup sees different information on each brick, determining that
some bricks are corrupted and incorrectly excluding them from the
operation and initiating a self-heal. In some cases this false
detection combined with self-heal could lead to invalid updates of
the trusted.ec.size xattr, leaving the file smaller than it should
be.
This only happens if the first operation does not perform a lookup,
because chained operations reuse the information returned by the
previous one, avoiding this kind of problems.
To solve this, now the background update is executed atomically with
the posterior unlock. This avoids some reuses of the lock while
updating. However this reduces performance because the window in
which new requests can reuse the lock is much smaller now. This has
been alleviated by using the same technique implemented in AFR (i.e.
waiting some time before releasing the lock).
Some minor changes also introduced in this patch:
* Bug in management of 'trusted.glusterfs.pathinfo' that was writing
beyond the allocated space.
* Uninitialized variable.
* trusted.ec.config was not created for regular files created with
mknod.
* An invalid state was used in access fop.
This is a backport of http://review.gluster.org/8947/
Change-Id: Idfaf69578ed04dbac97a62710326729715b9b395
BUG: 1152903
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/8948
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of http://review.gluster.org/8918
http://review.gluster.org/8955
Problem:
Just after replace-brick the mount logs are filled with ENOENT/ESTALE
warning logs because the file is yet to be self-healed now that the
brick is new.
Fix:
Do conditional logging for the logs. ENOENT/ESTALE will be logged at
lower log level. Only when debug logs are enabled, these logs will
be written to the logfile.
Change-Id: If203d09e2479e8c2415ebc14fb79d4fbb81dfc95
BUG: 1155027
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
Reviewed-on: http://review.gluster.org/8957
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Krutika Dhananjay <kdhananj@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of http://review.gluster.org/8536
All the special cases v1 handles and also
self-accusing pending changelog from v1 pre-op also is handled
in this patch.
BUG: 1155017
Change-Id: I86cf6b80492be5c1f240c74f91a0e1b0dd9b58b2
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
Reviewed-on: http://review.gluster.org/8956
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Doing an 'ls' of a directory that has been modified while one
of the bricks was down, sometimes returns the old directory
contents.
Cause: Directories are not marked when they are modified as files are.
The ec xlator balances requests amongst available and healthy
bricks. Since there is no way to detect that a directory is
out of date in one of the bricks, it is used from time to time
to return the directory contents.
Solution: Basically the solution consists in use versioning information
also for directories, however some additional changes have
been necessary.
Changes:
* Use directory versioning:
This required to lock full directory instead of a single entry for
all requests that add or remove entries from it. This is needed to
allow atomic version update. This affects the following fops:
create, mkdir, mknod, link, symlink, rename, unlink, rmdir
Another side effect is that opendir requires to do a previous
lookup to get versioning information and discard out of date
bricks for subsequent readdir(p) calls.
* Restrict directory self-heal:
Till now, when one discrepancy was found in lookup, a self-heal
was automatically started. This caused the versioning information
of a bad directory to be healed instantly, making the original
problem to reapear again.
To solve this, when a missing directory is detected in one or more
bricks on lookup or opendir fops, only a partial self-heal is
performed on it. A partial self-heal basically creates the
directory but does not restore any additional information.
This avoids that an 'ls' could repair the directory and cause the
problem to happen again. With this change, output of 'ls' is
always consistent. However, since the directory has been created
in the brick, this allows any other operation on it (create new
files, for example) to succeed on all bricks and not add additional
work to the self-heal process.
To force a self-heal of a directory, any other operation must be
done on it. For example a getxattr.
With these changes, the correct healing procedure that would avoid
inconsistent directory browsing consists on a post-order traversal
of directoriesi being healed. This way, the directory contents will
be healed before healing the directory itslef.
* Additional changes to fix self-heal errors
- Don't use fop->fd to decide between fd/loc.
open, opendir and create have an fd, but the correct data is in
loc.
- Fix incorrect management of bad bricks per inode/fd.
- Fix incorrect selection of fop's target bricks when there are bad
bricks involved.
- Improved ec_loc_parent() to always return a parent loc as
complete as possible.
This is a backport of http://review.gluster.org/8916/
Change-Id: Iaf3df174d7857da57d4a87b4a8740a7048b366ad
BUG: 1149727
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/8946
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When GlusterD starts the brick processes, these will listen on all
interfaces. When the 'transport.socket.bind-address' option is set in
glusterd.vol, the brick processes should only listen on the specified
hostname or IP-address.
Cherry picked from commit 430b874c4f1a171c106a9e1e6507e14e79805a1d:
> Change-Id: I8e7d1f294904081137c23f3446261329d0d13bba
> BUG: 1149863
> Signed-off-by: Niels de Vos <ndevos@redhat.com>
> Reviewed-on: http://review.gluster.org/8910
> Tested-by: Gluster Build System <jenkins@build.gluster.com>
> Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
> Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
Change-Id: I8e7d1f294904081137c23f3446261329d0d13bba
BUG: 1151745
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/8951
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the transport.socket.bind-address option is set to a hostname or
ip-address, the services started by GlusterD fail to connect to the
management daemon. GlusterD always forces the services to connect to the
"localhost" hostname, even if it is not listening on that address.
GlusterD should take the transport.socket.bind-address option into
consideration, and pass that to the glusterfs-clients with the -s or
--volfile commandline parameter.
Note that this is not a change that removes all hard-coded dependencies
on "localhost". This change merely makes it possible to start required
services when the transport.socket.bind-address option is set.
Cherry picked from commit 283fa797f4bf98130b42c36972305b8cb6e5aaaf:
> Change-Id: I36a0ed6c69342e6327adc258fea023929055d7f2
> BUG: 1149863
> Signed-off-by: Niels de Vos <ndevos@redhat.com>
> Reviewed-on: http://review.gluster.org/8908
> Tested-by: Gluster Build System <jenkins@build.gluster.com>
> Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
> Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
> Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
Change-Id: I36a0ed6c69342e6327adc258fea023929055d7f2
BUG: 1151745
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/8950
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some additional 32 bits issues have been added by a recent patch.
This patch solves it.
This is a backport of http://review.gluster.org/8882/
Change-Id: Ice81032fbe8e36e5ccad19a781b7876891993906
BUG: 1146904
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/8883
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The final lookup made to restore final file attributes after a self-heal
did clear the mask of bad bricks, causing that the final setattr won't
modify any brick at all. This caused that some attriutes, specially the
modification time of the file didn't get updated properly.
Now the mask of healed bricks is saved before doing the last lookup.
It's also used to correctly report the repaired bricks.
This is a backport of http://review.gluster.org/8905/
Change-Id: Ib94083c9e1b562515dfb54f9574120f1f031dccc
BUG: 1149725
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/8906
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a backport of http://review.gluster.org/8891/
Change-Id: I4504f3050674dde217e79af28cb4d2b5370fe2d5
BUG: 1148093
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/8899
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Use a system-dependent macro for umount(8) location instead of
relying on $PATH to find it, for security and portability sake.
2) Introduce gf_umount_lazy() to replace umount -l (-l for lazy) invocations,
which is only supported on Linux; On Linux behavior in unchanged. On other
systems, we fork an external process (umountd) that will take care of
periodically attempt to unmount, and optionally rmdir.
Backport of Ia91167c0652f8ddab85136324b08f87c5ac1edd51d
BUG: 1138897
Change-Id: I9d82c87e85af0dee79f2de39bc697c486b7103c8
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/8863
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Csaba Henk <csaba@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
POSIX mandates the filesystem to support paths of lengths up to
_XOPEN_PATH_MAX (1024). This is the PATH_MAX limit here:
http://pubs.opengroup.org/onlinepubs/009604499/basedefs/limits.h.html
When using a path of 1023 bytes, the posix xlator attempts to create
an absolute path by prefixing the 1023 bytes path by the brick
base path. The result is an absolute path of more than _XOPEN_PATH_MAX
bytes which may be rejected by the backend filesystem.
Linux's ext3fs PATH_MAX seems to defaut to 4096, which means it
will work (except if brick base path is longer than 2072 bytes but
it is unlikely to happen. NetBSD's FFS PATH_MAX defaults to 1024,
which means the bug can happen regardless of brick base path length.
If this condition is detected for a brick, the proposed fix is to
chdir() the brick glusterfsd daemon to its brick base directory.
Then when encountering a path that will exceed _XOPEN_PATH_MAX once
prefixed by the brick base path, a relative path is used instead
of an absolute one. We do not always use relative path because some
operations require an absolute path on the brick base path itself
(e.g.: statvfs).
At least on NetBSD, this chdir() uncovers a race condition which
causes file lookup to fail with ENODATA for a few seconds. The
volume quickly reaches a sane state, but regression tests are fast
enough to choke on it. The reason is obscure (as often with race
conditions), but sleeping one second after the chdir() seems to
change scheduling enough that the problem disapear.
Note that since the chdir() is done if brick backend filesystem
does not support path long enough, it will not occur with Linux
ext3fs (except if brick base path is over 2072 bytes long).
This is a backport of I7db3567948bc8fa8d99ca5f5ba6647fe425186a9
BUG: 1138897
Change-Id: Ib8eb3efaac8a7ba505d830623921338689229e9a
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/8864
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Harshavardhana <harsha@harshavardhana.net>
Tested-by: Harshavardhana <harsha@harshavardhana.net>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Operations processed by ec_dispatch_one() were not correctly
completed by ec_complete(), leaving some structures in memory.
Now ec_complete() also calls ec_resume() for this type of fops.
This is a backport of http://review.gluster.org/8896/
Change-Id: Iaf0f2e8227399ebb735db9f1bd007593e0ece041
BUG: 1148521
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/8897
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to POSIX, seekdir() should only be given offset obtained from
telldir() on the same DIR *
http://pubs.opengroup.org/onlinepubs/9699919799/functions/seekdir.html
Code from afr-self-heald.c and index.c is operating outside of the
specification, by doing using seekdir() with offset from a previously
open/close/re-open directory. This seems to work on Linux (although with
no guarantee it will always in the future). On NetBSD the seekdir()
with a in invalid offset is a nilpotent operation, and causes an infinite
loop, since index_fill_readdir() always restart from the beginning of the
directory.
The situation is fixed by using a non anonymous fd in afr-self-heald.c:
we explicitely open the directory so that it remains open on the brick
side during the timeframe where we want to reuse offsets in seekdir().
This requires adding an opendir fop in index xlator.
If the brick was not updated, the opendir will fail and we fallback
to the standard violating approach for backward compatibility on Linux.
On other systems we fail since it never worked.
While there, add tests to check seekdir() success in index and posix
xlators, so that incorrect usage from calling code produce an explicit
error instead of an infinite loop. We can only do it on non Linux systems,
for the sake of backward compatibility when the brick was updated but
not the client.
Backport of I88ca90acfcfee280988124bd6addc1a1893ca7ab
BUG: 1138897
Change-Id: I5446a9a17d5451ec5aab8fbd10d381da9a0a23ad
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/8860
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a backport of http://review.gluster.org/#/c/8878/
The pgfid extended attributes are used to construct the ancestry path
(from the file to the volume root) for nameless lookups on files.
As NFS relies on nameless lookups heavily, quota enforcement through NFS
would be inconsistent if quota were to be enabled on a volume with
existing data.
Solution is to heal the pgfid extended attributes as a part of lookup
perfomed by quota-crawl process. In a posix lookup check for pgfid xattr
and if it is missing set the xattr.
BUG: 1147953
Change-Id: I707d91a056e07452bfd1e070af5eddaa752a84ac
Signed-off-by: vmallika <vmallika@redhat.com>
Reviewed-on: http://review.gluster.org/8890
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of: http://review.gluster.org/8868
Sending appropriate return value from afr_selfheal()
fixes the issue.
Credits : Krutika Dhananjay and Pranith Kumar.
Change-Id: I1dc8105078e99dbc12295ef557a407bf3d8cfec3
BUG: 1147486
Signed-off-by: Anuradha <atalur@redhat.com>
Reviewed-on: http://review.gluster.org/8884
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
File goes into split-brain because of wrong erasing of xattrs.
RCA:
The issue happens because index self-heal is triggered even before all the
bricks are up. So what ends up happening while erasing the xattrs is, xattrs
are erased only on the sink brick for the brick that it thinks is up leading to
split-brain
Example:
lets say the xattrs before heal started are:
brick 2:
trusted.afr.vol1-client-2=0x000000020000000000000000
trusted.afr.vol1-client-3=0x000000020000000000000000
brick 3:
trusted.afr.vol1-client-2=0x000010040000000000000000
trusted.afr.vol1-client-3=0x000000000000000000000000
if only brick-2 came up at the time of triggering the self-heal only
'trusted.afr.vol1-client-2' is erased leading to the following xattrs:
brick 2:
trusted.afr.vol1-client-2=0x000000000000000000000000
trusted.afr.vol1-client-3=0x000000020000000000000000
brick 3:
trusted.afr.vol1-client-2=0x000010040000000000000000
trusted.afr.vol1-client-3=0x000000000000000000000000
So the file goes into split-brain.
BUG: 1142612
Change-Id: I0c8b66e154f03b636db052c97745399a7cca265b
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
Reviewed-on: http://review.gluster.org/8756
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Krutika Dhananjay <kdhananj@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of: http://review.gluster.org/8875
Change-Id: Ib000be1238d38f8d63ff25b3873bb813bf72beec
BUG: 1145914
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
Reviewed-on: http://review.gluster.org/8876
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today, when glusterd's internal locking mechanism fails
with invalid type or when another competing lock is being
held, the log message doesn't provide enough information
directly as to which command saw this (first). Following
is a snippet of how a failure would look in the log file.
This would greatly assist in debugging.
[2014-09-03 04:57:58.549418] E
[glusterd-locks.c:520:glusterd_mgmt_v3_lock]
(-->/usr/local/lib/glusterfs/3.7dev/xlator/mgmt/glusterd.so(__glusterd_handle_create_volume+0x801)
[0x7f30b071e651]
(-->/usr/local/lib/glusterfs/3.7dev/xlator/mgmt/glusterd.so(glusterd_op_begin_synctask+0x2c)
[0x7f30b072e19c]
(-->/usr/local/lib/glusterfs/3.7dev/xlator/mgmt/glusterd.so(gd_sync_task_begin+0x55d)
[0x7f30b072de6d]))) 0-management: Invalid entity. Cannot perform locking
operation on vol types
Change-Id: I0595f49d60e620e8b065f3506bdb147ccee383a7
BUG: 1145093
Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-on: http://review.gluster.org/8842
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linux fallocate() differs from posix_fallocate() by
an extra flag that can have the FALLOC_FL_KEEP_SIZE value;
Do not test FALLOC_FL_KEEP_SIZE existence to enable fallocate()
in posix xlator, as sys_fallocate() in libglusterfs provides
support for both implementations.
Backport of Idf41a0396028a15e81281791bf6912d7fd674e3f
BUG: 1138897
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Change-Id: Ie6e5ea923561630c52a6db5c7f83313cfdc34811
Reviewed-on: http://review.gluster.org/8862
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of: http://review.gluster.org/8852
Change-Id: I2c927092dc5a834fabdd3495a7f7a3527604a6d2
BUG: 1136831
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
Reviewed-on: http://review.gluster.org/8869
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of: http://review.gluster.org/#/c/8837/
Original reporter of the bug & designer of the solution:
Pranith Kumar K <pkarampu@redhat.com>
Change-Id: I6e36326e1d9398ede82166b358ab438367dd3011
BUG: 1136829
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
Reviewed-on: http://review.gluster.org/8845
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure off_t and not size_t is used when holding file offsets for
ftruncate()/truncate(). It works on 64 bit machines where
sizeof(size_t) == sizeof(off_t) == 8, but breaks for big offsets on 32 bit
machines because sizeof(size_t) == 4 and sizeof(off_t) == 8
This is backport of Ia2637be772ba9b11731d59fdbffbd269f0ff56c8
BUG: 1138897
Change-Id: I8fe77a86831f0db4eff5b5c89efe004b9a0b29e9
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/8743
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Introduced in "1f6e992f1aaa676be5bd47d17e58f1171825cf43"
Change-Id: Id684e2f082def7d01ef3c258ea6598da6205591f
BUG: 1117822
Signed-off-by: Harshavardhana <harsha@harshavardhana.net>
Reviewed-on: http://review.gluster.org/8840
Reviewed-by: Justin Clift <justin@gluster.org>
Tested-by: Justin Clift <justin@gluster.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of http://review.gluster.org/8709
- Added logging for metadata and data self-heals which helped
in debugging this issue.
- Added checks to skip self-heals when no sinks are available to heal
BUG: 1145987
Change-Id: Ide03af4f531a1280ec8ad95b627285df4d7bc42d
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
Reviewed-on: http://review.gluster.org/8832
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
backport of: http://review.gluster.org/8821
AFR_STACK_RESET previously didn't cleanup afr_local_t,
leading to memory leaks. With this patch, cleanup is
done.
All credit goes to Pranith Kumar Karampuri.
Change-Id: I26506dfd9273b917eff5127c3e0cf9421e60f228
BUG: 1145914
Reviewed-on: http://review.gluster.org/8831
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turn setfattr(1) absolute path into an OS-dependant macro. Let compiler
option override it to fit custom installation if needed.
Backport of I8f469c5741a85b6e8d8f6299a9540b3d64611d2f
BUG: 1138897
Change-Id: I279752f2ec5db1abc25830cb9a23290cc401d517
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/8828
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, moved the backtrace fetching logic to a separate function.
Modified the backtrace fetching logic able to work under memory pressure
conditions.
Change-Id: Ie38bea425a085770f41831314aeda95595177ece
BUG:1145093
Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-on: http://review.gluster.org/8794
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Atin Mukherjee <amukherj@redhat.com>
Reviewed-by: Niels de Vos <ndevos@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of
371bb42 glusterd: Authenticate management handshake requests
from master.
Management handshake requests, which are used to validate op-version
supported by the peers, are now only allowed if,
- the glusterd doesn't have any other peer, or
- the request was sent by another peer.
This prevents the op-version of a peer being changed because of a
connection attempt by an invalid peer.
BUG: 1144978
Change-Id: I5a909dad37e9873efe8b75dad41b7af71ce91c3d
Signed-off-by: Kaushal M <kaushal@redhat.com>
Reviewed-on: http://review.gluster.org/8819
Reviewed-by: Atin Mukherjee <amukherj@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To simplify backward compatibility of the ec xlator when some
parameter or the implementation itself is changed, a new xattr
is added to each file with the configuration needed to recover
it.
The new attribute is called 'trusted.ec.config', and it's a 64-bit
value containing the following information:
8 bits: version of the config information (currently always 0)
8 bits: algorithm used to encode the file (currently always 0)
8 bits: size of the galois field (currently always 8)
8 bits: number of bricks
8 bits: redundancy
24 bits: chunk size (currently 512)
This new xattr could allow, in a future version, to have different
configurations per file.
This is a backport of http://review.gluster.org/8770/
Change-Id: I8c12d40ff546cc201fc66caa367484be3d48aeb4
BUG: 1140862
Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-on: http://review.gluster.org/8825
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of: http://review.gluster.org/8816
Change-Id: I8463a579f542a2336b02edba8f5fbfea0edbbffe
BUG: 1136829
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
Reviewed-on: http://review.gluster.org/8823
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of http://review.gluster.org/8698
Problem:
When self-heal code doesn't see at least 2 successes on looking up children,
then self-heal can't be done. What is happening now is if all the lookups fail
then the pending changelog is all zeros in xattrs so all the children are
becoming sources and leading to crashes when the code paths further assume that
some data structures are populated properly
Fix:
Don't proceed with self-heals when < 2 children succeed lookups.
BUG: 1145726
Change-Id: I65465843f0e554c8ccdd8fa930ab42ac123ec023
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
Reviewed-on: http://review.gluster.org/8824
Reviewed-by: Krutika Dhananjay <kdhananj@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of: http://review.gluster.org/8296
Problem:
The xattr healing part of the marker requires path to be present in the loc.
Currently path is not filled while triggering from the readdirp_cbk.
Solution:
Current patch tries to fill the loc with path.
Change-Id: I2e2589ecfa6b6a6e27407c9541fa90a314649bec
BUG: 1145623
Signed-off-by: Varun Shastry <vshastry@redhat.com>
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
Reviewed-on: http://review.gluster.org/8820
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Default 'open FD limit' is 1024. As the number of volumes/bricks
increases, brick-to-glusterd socket FDs also increases in glusterd and
runs out of the limit.
Solution is to set the 'Open FD' limit to higher value in glusterd
Change-Id: Iaa60b2155df2fa5a0759e054bdebffbc09f63ec1
BUG: 1145095
Signed-off-by: Vijaikumar M <vmallika@redhat.com>
Reviewed-on: http://review.gluster.org/8578
Reviewed-by: Rajesh Joseph <rjoseph@redhat.com>
Reviewed-by: Atin Mukherjee <amukherj@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
Signed-off-by: Sachin Pandit <spandit@redhat.com>
Reviewed-on: http://review.gluster.org/8807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As one of the recommandations for taking a snapshot is not to have
an active geo-replication session, its better to display an error
saying session is active when snapshot create command is issued.
Change-Id: I94593dbd2659610e033ca316176dda1ac8dc5ce6
BUG: 1145091
Signed-off-by: Sachin Pandit <spandit@redhat.com>
Reviewed-on: http://review.gluster.org/8461
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Rajesh Joseph <rjoseph@redhat.com>
Reviewed-by: Atin Mukherjee <amukherj@redhat.com>
Reviewed-by: Vijaikumar Mallikarjuna <vmallika@redhat.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
Signed-off-by: Sachin Pandit <spandit@redhat.com>
Reviewed-on: http://review.gluster.org/8804
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
creating snapshots.
When creating a snapshot a LVM is created at the backend and is mounted
under /var/run/gluster/snaps/... However, this mount does not inherit
the mount options for the original brick acting as the parent for the
snap.
If the snap is restored, this could lead to performance degredations,
functional limitations, or in extreme scenarios even potential data
loss.
Change-Id: I67d70fd83430d83dacc5380c6c928e27fb9c9e1b
BUG: 1145088
Signed-off-by: Vijaikumar M <vmallika@redhat.com>
Reviewed-on: http://review.gluster.org/8394
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
Signed-off-by: Sachin Pandit <spandit@redhat.com>
Reviewed-on: http://review.gluster.org/8802
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aligned with error messages of info and list.
When a snapshot operation like status, info, list
performed on a non-existing snapshot.
For Status error message is displayed as 'Snap not found'
For List and Info error message is displayed as 'Snapshot does not exist'
Have the consistant error message all the places
Change-Id: I7b241217dba62fda844481731a6858e4ecb12897
BUG: 1145087
Signed-off-by: Vijaikumar M <vmallika@redhat.com>
Reviewed-on: http://review.gluster.org/8309
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
Signed-off-by: Sachin Pandit <spandit@redhat.com>
Reviewed-on: http://review.gluster.org/8801
Tested-by: Gluster Build System <jenkins@build.gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
problem: Snapshot command fails if one or more bricks are not thinly
provisioned. But the error message is a generic error message which
is confusing to the user.
fix: Provide correct error message in case of failure.
Change-Id: Iad247f966423a8f73ef6da57cab7ed6cddc05861
BUG: 1145086
Signed-off-by: Rajesh Joseph <rjoseph@redhat.com>
Reviewed-on: http://review.gluster.org/8377
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
Signed-off-by: Sachin Pandit <spandit@redhat.com>
Reviewed-on: http://review.gluster.org/8800
Reviewed-by: Vijaikumar Mallikarjuna <vmallika@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as-well-as to a particular volume
Problem :
With the current design we can only delete a single snapshot.
And the deletion of volume which contains snapshot is not allowed.
Because of that user might be forced to delete all the snapshots
manually before he is allowed to delete a volume.
Solution:
Following is the interface with which user can delete
all the snapshots of a system or belonging to a particular volume.
Syntax : gluster snapshot delete all
*To delete all the snapshots present in a system
Syntax : gluster snapshot delete volume <volname>
*To deletes all the snapshot present in a volume specified.
========================================================================
Sample Output:
Case 1 : Deleting a single snapshot.
[root@snapshot-24 glusterfs]# gluster snapshot delete snap1
Deleting snap will erase all the information about the snap. Do you still want to continue? (y/n) y
snapshot delete: snap1: snap removed successfully
-----------------------------------------------------------------
Case 2 : Deleting all the snapshots in a Volume.
[root@snapshot-24 glusterfs]# gluster snapshot delete volume vol1
Volume (vol1) contains 9 snapshot(s).
Do you still want to continue and delete them? (y/n) y
snapshot delete: snap2: snap removed successfully
snapshot delete: snap3: snap removed successfully
snapshot delete: snap4: snap removed successfully
snapshot delete: snap5: snap removed successfully
.
.
.
-----------------------------------------------------------------
Case 3 : Deleting all the snapshots in a system.
[root@snapshot-24 glusterfs]# gluster snapshot delete all
System contains 4 snapshot(s).
Do you still want to continue and delete them? (y/n) y
snapshot delete: snap7: snap removed successfully
snapshot delete: snap8: snap removed successfully
snapshot delete: snap9: snap removed successfully
snapshot delete: snap10: snap removed successfully
========================================================================
Change-Id: Ifec8e128ab2011cbbba208376b9c92cfbe7d8d71
BUG: 1145083
Signed-off-by: Sachin Pandit <spandit@redhat.com>
Reviewed-on: http://review.gluster.org/8162
Reviewed-by: Atin Mukherjee <amukherj@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Avra Sengupta <asengupt@redhat.com>
Reviewed-by: Raghavendra Bhat <raghavendra@redhat.com>
Reviewed-by: Kaushal M <kaushal@redhat.com>
Signed-off-by: Sachin Pandit <spandit@redhat.com>
Reviewed-on: http://review.gluster.org/8798
Reviewed-by: Vijaikumar Mallikarjuna <vmallika@redhat.com>
|