Bug 1165663

Summary:	[USS]: Inconsistent behaviour when a snapshot is default deactivated and when it is activated and than deactivated
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Rahul Hinduja <rhinduja>
Component:	snapshot	Assignee:	Vijaikumar Mallikarjuna <vmallika>
Status:	CLOSED ERRATA	QA Contact:	senaik
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	annair, asengupt, rhs-bugs, rjoseph, rkavunga, senaik, smohan, storage-qa-internal, vagarwal, vmallika
Target Milestone:	---
Target Release:	RHGS 3.1.0
Hardware:	x86_64
OS:	Linux
Whiteboard:	USS
Fixed In Version:	glusterfs-3.7.0-3.el6rhs	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-29 04:36:50 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1202842, 1223636

Description Rahul Hinduja 2014-11-19 13:04:24 UTC

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

Comment 2 Vijaikumar Mallikarjuna 2014-11-20 07:15:26 UTC

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>.

Comment 4 Mohammed Rafi KC 2015-04-01 05:54:51 UTC

Fixed in upstream, now accessing .snaps will be successful once uss is activated.

Comment 6 senaik 2015-06-23 08:26:05 UTC

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'

Comment 8 errata-xmlrpc 2015-07-29 04:36:50 UTC

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