Red Hat Bugzilla – Bug 1165663
[USS]: Inconsistent behaviour when a snapshot is default deactivated and when it is activated and than deactivated
Last modified: 2016-09-17 09:04:16 EDT
Description of problem: ======================= Entering to the .snaps from fuse has different behaviour when a snapshot is default deactivated (during creation) and when it is deactivated (activate=>deactivate) Behaviour 1: When a snapshot is created, it is default deactivated and if you try to cd <dir>/.snaps it fails as expected with "No such file or directory" Behaviour 2: Now if the snap is activated and than deactivated and if you now try to cd <dir>/.snaps it is successful and does not list any snaps In both the above behaviours the snap in which dir is participating is deactivate, but it allows to enter in behaviour 2 and fails in behaviour 1 Behaviour has to be consistent for deactivated OR activated snaps Version-Release number of selected component (if applicable): ============================================================= glusterfs-3.6.0.33-1.el6rhs.x86_64 How reproducible: ================= always Steps to Reproduce: =================== 1. Create 4 node cluster 2. Create 2x2 volume 3. Mount the volume on client (fuse) on /mnt/ 4. create a directory dir 5. Enable the uss on volume 6. create a snapshot snap1 of volume 7. From client, cd to /mnt/dir/.snaps, it fails "no such file or directory" 8. activate the snap1 9. From client, cd to /mnt/dir/.snaps, it is successful and list snap1 10. cd .. 11. Deactivate the snap1 12 From client, cd to /mnt/dir/.snaps, it is still successful but does not list the snap1 Actual results: =============== Inconsistent behaviour at step 7 and 12 where snap1 is deactivated Expected results: ================= Behaviour should be consisted when a snapshot is deactivated
When you cd to <dir>/.snap for the first time when no snapshot is available which contains this directory will fail. This is because gfid of <dir> is not yet resolved in the protocol server at this time. When snapshot is activated and when you cd <dir>/.snaps. gfid of <dir> get resolved and stored in inode-table. Now when snapshot gets deactivated and cd to <dir>/.snaps/ gfid-resolve will not be done again for the <dir>.
Fixed in upstream, now accessing .snaps will be successful once uss is activated.
Version : glusterfs-3.7.1-4.el6rhs.x86_64 1) Create volume enable USS 2) On client create directory a from fuse mount and b from NFS mount 3) Create a snapshot S1 . This snapshot is default deactivated. cd to .snaps from client. Fuse mount : =========== cd to .snaps [root@dhcp35-63 vol0_fuse]# cd a/ [root@dhcp35-63 a]# cd .snaps [root@dhcp35-63 .snaps]# ll total 0 NFS mount : ========== [root@dhcp35-63 vol0_nfs]# cd b [root@dhcp35-63 b]# cd .snaps [root@dhcp35-63 .snaps]# ll total 0 4) Activate the snapshot and list under .snaps - successful 5) Deactivate the snapshot and list under .snaps Fuse mount: ========== [root@dhcp35-63 a]# cd .snaps [root@dhcp35-63 .snaps]# ll total 0 NFS mount : ========= [root@dhcp35-63 b]# cd .snaps [root@dhcp35-63 .snaps]# ll total 0 Behaviour is consistent as mentioned in Description in Scenario 1 and 2. Marking the bug 'Verified'
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-1495.html