+++ 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>
From the description and the comment this bug seems exactly same as 1158791. Therefore closing this bug as Duplicate. *** This bug has been marked as a duplicate of bug 1158791 ***