summaryrefslogtreecommitdiffstats
path: root/tests/basic/uss.t
diff options
context:
space:
mode:
authorRaghavendra Bhat <raghavendra@redhat.com>2014-10-09 17:32:48 +0530
committerVijay Bellur <vbellur@redhat.com>2014-10-28 00:08:10 -0700
commit1fa3e87db77bb379173723a5e75b361a8e192f09 (patch)
tree0001e771a1693a078680ead5ebd1cf053d349872 /tests/basic/uss.t
parent2855dff243f20a78cd8cc4e7cd581a9c558b2e69 (diff)
features/snapview-server: check if the reference to the snapshot world is
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: Idca0c8015ff632447cea206a4807d8ef968424fa BUG: 1151004 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> Reviewed-on: http://review.gluster.org/8917 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Diffstat (limited to 'tests/basic/uss.t')
-rw-r--r--tests/basic/uss.t36
1 files changed, 36 insertions, 0 deletions
diff --git a/tests/basic/uss.t b/tests/basic/uss.t
index 04d4baf64a5..2ce78bb682b 100644
--- a/tests/basic/uss.t
+++ b/tests/basic/uss.t
@@ -274,4 +274,40 @@ function count_snaps
EXPECT_WITHIN 30 "5" count_snaps $M0;
+# deletion of a snapshot and creation of a new snapshot with same name
+# should not create problems. The data that was supposed to be present
+# in the deleted snapshot need not be present in the new snapshot just
+# because the name is same. Ex:
+# 1) Create a file "aaa"
+# 2) Create a snapshot snap6
+# 3) stat the file "aaa" in snap6 and it should succeed
+# 4) delete the file "aaa"
+# 5) Delete the snapshot snap6
+# 6) Create a snapshot snap6
+# 7) stat the file "aaa" in snap6 and it should fail now
+
+echo "aaa" > $M0/aaa;
+
+TEST $CLI snapshot create snap6 $V0
+
+TEST ls $M0/.history;
+
+EXPECT_WITHIN 30 "6" count_snaps $M0;
+
+TEST stat $M0/.history/snap6/aaa
+
+TEST rm -f $M0/aaa;
+
+TEST $CLI snapshot delete snap6;
+
+TEST $CLI snapshot create snap6 $V0
+
+TEST ls $M0/.history;
+
+EXPECT_WITHIN 30 "6" count_snaps $M0;
+
+TEST ls $M0/.history/snap6/;
+
+TEST ! stat $M0/.history/snap6/aaa;
+
cleanup;