Description of problem: ======================= In a scenarion where snapshotted volume is mounted on the client and the original mounted is restored. The already mounted snapshotted volume doesn't give "Transport end-point not connected", it still lists the files in read-only. For example: ============ Snapshoted volume is mounted on a client and data is present on it: =================================================================== [root@wingo ~]# mount -t glusterfs inception.lab.eng.blr.redhat.com:/snaps/SR1/vol3 /mnt/SR1 [root@wingo ~]# cd /mnt/SR1 [root@wingo SR1]# ls 1 11 13 15 17 19 20 4 6 8 file.1 file.2 file.4 file.6 file.8 nfile.1 nfile.2 nfile.4 nfile.6 nfile.8 10 12 14 16 18 2 3 5 7 9 file.10 file.3 file.5 file.7 file.9 nfile.10 nfile.3 nfile.5 nfile.7 nfile.9 [root@wingo SR1]# Volume is restored to its snapshot SR1 and started: =================================================== [root@inception ~]# gluster snapshot restore SR1 Snapshot restore: SR1: Snap restored successfully [root@inception ~]# gluster v start vol3 volume start: vol3: success [root@inception ~]# Look into the already mounted snapshoted volume SR1: ==================================================== [root@wingo ~]# cd /mnt/SR1 [root@wingo SR1]# ls 1 11 13 15 17 19 20 4 6 8 file.1 file.2 file.4 file.6 file.8 nfile.1 nfile.2 nfile.4 nfile.6 nfile.8 10 12 14 16 18 2 3 5 7 9 file.10 file.3 file.5 file.7 file.9 nfile.10 nfile.3 nfile.5 nfile.7 nfile.9 [root@wingo SR1]# Even when the volume(vol3) is restored to its snapshot(SR1), the snapshot SR1 is deleted during restore but the already mounted client is able to access it as earlier. From the usability it should be inaccessible. Version-Release number of selected component (if applicable): ============================================================= glusterfs-3.6.0.28-1.el6rhs.x86_64 How reproducible: ================= always Steps to Reproduce: =================== 1. Create 4 node cluster 2. Create a volume (vol3) 3. Mount the volume to the client (/mnt/vol3) 4. Add some data to the client 5. Create a snapshot of a volume (SR1) 6. Mount the snapshot of the volume to the client (/mnt/SR1). It should be mountable and should be in read-only 7. Stop the volume (vol3) 8. Restore the volume to its snapshot (SR1) 9. Start the volume (vol3) 10. Access the already snapshoted volume (/mnt/SR1) Actual results: =============== Able to access the files in read-only mode Expected results: ================= When a snapshot is deleted as part of the restore the already snapshoted volume client should error out complaining "Transport end-point not connected" as in real the snapshot SR1 doesn't exist USS might see a impact as the user who is already monitoring the snapshoted volume after restore will keep see the updated data not the snapshoted data.
This happens with below scenario as well: 1) Create a volume 2) Mount the volume 3) Stop and Delete the volume 4) Create the new volume with the same set of bricks 5) Client automatically connects to the new bricks and able to access the mount point
As explained in Comment 2, snapshotted volumes inherit this behaviour from gluster volumes in general. Moving this out of snapshot.
This issue has been fixed in 3.1.3
As per comment 5, moving the state to ON_QA