Bug 1158791 - [USS]: deletion and creation of snapshots with same name causes problems
Summary: [USS]: deletion and creation of snapshots with same name causes problems
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: snapshot
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Raghavendra Bhat
QA Contact:
URL:
Whiteboard:
: 1157985 (view as bug list)
Depends On: 1151004
Blocks: 1157452 1157985
TreeView+ depends on / blocked
 
Reported: 2014-10-30 09:03 UTC by Raghavendra Bhat
Modified: 2016-08-23 11:55 UTC (History)
2 users (show)

Fixed In Version: glusterfs-3.6.1
Doc Type: Bug Fix
Doc Text:
Clone Of: 1151004
Environment:
Last Closed: 2014-11-10 15:14:35 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Raghavendra Bhat 2014-10-30 09:03:56 UTC
+++ This bug was initially created as a clone of Bug #1151004 +++

Description of problem:

The deletion and recreation of a snapshot with same name creates problems while accessing the contents of newly created snapshot bu giving ENOTCONN errors.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create a file on the glusterfs mount point
2. Create a snapshot "snap1"
3. delete the file
4. delete the snapshot "snap1"
5. create a snapshot "snap1"
6. try to access snap1

Actual results:
applications get ENOTCONN

Expected results:
Applications should not get ENOTCONN

Additional info:
When the snapshot "snap1" is created first time and accessed (<mount point>/<entry point>/snap1/<filename>), a new inode and dentry were created for snap1 with parent being the entry point. Within the inode context the glfs_t instance to access the snapshot and the handle to access the inode in the snapshot world (or gfapi world in this case) is saved. But when the snapshot was deleted and recreated, a new glfs_t instance is established (older one being destroyed). So to access snap1 now, we have to do yet another lookup and save the glfs_t instance and the new handle within the inode context. Since that was not being done, older glfs_t instance was still used which gave ENOTCONN when accessed as the corresponding snapshot volume does not exist anymore.

--- Additional comment from Anand Avati on 2014-10-09 08:30:19 EDT ---

REVIEW: http://review.gluster.org/8917 (features/snapview-server: check if the reference to the snapshot world is correct before doing any fop) posted (#1) for review on master by Raghavendra Bhat (raghavendra)

--- Additional comment from Anand Avati on 2014-10-10 03:35:18 EDT ---

REVIEW: http://review.gluster.org/8917 (features/snapview-server: check if the reference to the snapshot world is correct before doing any fop) posted (#2) for review on master by Raghavendra Bhat (raghavendra)

--- Additional comment from Anand Avati on 2014-10-28 03:08:14 EDT ---

COMMIT: http://review.gluster.org/8917 committed in master by Vijay Bellur (vbellur) 
------
commit 1fa3e87db77bb379173723a5e75b361a8e192f09
Author: Raghavendra Bhat <raghavendra>
Date:   Thu Oct 9 17:32:48 2014 +0530

    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>
    Reviewed-on: http://review.gluster.org/8917
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Vijay Bellur <vbellur>

--- Additional comment from Anand Avati on 2014-10-28 05:33:18 EDT ---

REVIEW: http://review.gluster.org/8986 (features/snapview-server: check if the reference to the snapshot world is correct before doing any fop) posted (#1) for review on release-3.6 by Raghavendra Bhat (raghavendra)

--- Additional comment from Anand Avati on 2014-10-29 08:19:59 EDT ---

REVIEW: http://review.gluster.org/8999 (features/snapview-server: verify the fs instance in revalidated lookups as well) posted (#1) for review on master by Raghavendra Bhat (raghavendra)

--- Additional comment from Anand Avati on 2014-10-30 04:49:42 EDT ---

COMMIT: http://review.gluster.org/8999 committed in master by Vijay Bellur (vbellur) 
------
commit 8ab61c18d5de81aa613130e8f65b2f420476c08e
Author: Raghavendra Bhat <raghavendra>
Date:   Wed Oct 29 17:47:48 2014 +0530

    features/snapview-server: verify the fs instance in revalidated lookups as well
    
    Change-Id: Id5f9d5a23eb5932a0a53520b08ffba258952e000
    BUG: 1151004
    Signed-off-by: Raghavendra Bhat <raghavendra>
    Reviewed-on: http://review.gluster.org/8999
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Vijay Bellur <vbellur>

Comment 1 Anand Avati 2014-10-30 09:06:31 UTC
REVIEW: http://review.gluster.org/9007 (features/snapview-server: check if the reference to the snapshot world is correct before doing any fop) posted (#1) for review on release-3.6 by Raghavendra Bhat (raghavendra)

Comment 2 Anand Avati 2014-10-30 09:06:34 UTC
REVIEW: http://review.gluster.org/9008 (features/snapview-server: verify the fs instance in revalidated lookups as well) posted (#1) for review on release-3.6 by Raghavendra Bhat (raghavendra)

Comment 3 Anand Avati 2014-10-30 18:39:24 UTC
COMMIT: http://review.gluster.org/9007 committed in release-3.6 by Vijay Bellur (vbellur) 
------
commit 2ebb417e7558a35990b7c2784d25fe38ea975d0e
Author: Raghavendra Bhat <raghavendra>
Date:   Thu Oct 9 17:32:48 2014 +0530

    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: I975245b8f6b7fea0a90eb5e36e8149d12457ac10
    BUG: 1158791
    Reviewed-on: http://review.gluster.org/9007
    Reviewed-by: Vijay Bellur <vbellur>
    Tested-by: Vijay Bellur <vbellur>

Comment 4 Anand Avati 2014-10-30 18:40:03 UTC
COMMIT: http://review.gluster.org/9008 committed in release-3.6 by Vijay Bellur (vbellur) 
------
commit c2326236e9bac86abe1131d34b018c7d5a87813f
Author: Raghavendra Bhat <raghavendra>
Date:   Wed Oct 29 17:47:48 2014 +0530

    features/snapview-server: verify the fs instance in revalidated lookups as well
    
    Change-Id: I691635e60aba72642c3c79d7da472884f1228301
    BUG: 1158791
    Reviewed-on: http://review.gluster.org/9008
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Vijay Bellur <vbellur>

Comment 5 Niels de Vos 2014-11-10 15:14:35 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.6.1, please reopen this bug report.

glusterfs-3.6.1 has been announced [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://supercolony.gluster.org/pipermail/gluster-users/2014-November/019410.html
[2] http://supercolony.gluster.org/mailman/listinfo/gluster-users

Comment 6 rjoseph 2016-08-23 11:55:51 UTC
*** Bug 1157985 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.