Bug 1170502

Summary: [USS]: If .snaps already exists, ls -la lists it even after enabling USS
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Rahul Hinduja <rhinduja>
Component: snapshotAssignee: Vijaikumar Mallikarjuna <vmallika>
Status: CLOSED NEXTRELEASE QA Contact: storage-qa-internal <storage-qa-internal>
Severity: high Docs Contact:
Priority: unspecified    
Version: rhgs-3.0CC: asengupt, asriram, nsathyan, rhs-bugs, rjoseph, smohan, storage-qa-internal, vmallika
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: USS
Fixed In Version: Doc Type: Known Issue
Doc Text:
On enabling the User Serviceable Snapshot feature, if a directory or a file by name '.snaps' exists on a volume, it appears in the output of the 'ls -a command'.
Story Points: ---
Clone Of:
: 1303593 (view as bug list) Environment:
Last Closed: 2016-02-01 11:54:45 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: 1159283, 1303595    
Bug Blocks: 1153907, 1303593, 1303828, 1306163    

Description Rahul Hinduja 2014-12-04 07:40:53 UTC
Description of problem:
=======================

If the snapshot-directory which bydefault is .snaps exists and it contains some data. After enabling USS, ls -la lists the .snaps (snapshot-directory) which will have adverse impact if user copies the complete directory which will copy the snapshots as well of .snaps.

We also have provision of configuring snapshot-directory, and with this user chances of seeing this is more.


[root@wingo test]# mount | grep vol0
inception.lab.eng.blr.redhat.com:/vol0 on /mnt/vol0 type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)
inception.lab.eng.blr.redhat.com:/vol0 on /mnt/nvol0 type nfs (rw,vers=3,addr=10.70.34.50)
[root@wingo test]#
[root@wingo test]# pwd
/mnt/vol0/test
[root@wingo test]#

Before enabling USS ls -la shows .snaps and its contents as:
============================================================

[root@wingo test]# ls -lrta
total 0
drwxr-xr-x. 3 root root  38 Dec  4  2014 .
drwxr-xr-x. 7 root root 140 Dec  4  2014 ..
drwxr-xr-x. 3 root root  36 Dec  4  2014 .snaps
[root@wingo test]#
[root@wingo test]# ls .snaps
etc.5
[root@wingo test]#


After enabling USS, ls -la still shows .snaps and its contents as snapshots:
=============================================================================

[root@wingo test]# pwd
/mnt/vol0/test
[root@wingo test]# ls -lrta
total 4
drwxr-xr-x. 7 root root  140 Dec  4  2014 ..
drwxr-xr-x. 3 root root   38 Dec  4  2014 .
drwxr-xr-x. 2 root root 4096 Dec  4  2014 .snaps
[root@wingo test]# ls .snaps
rs1  rs2
[root@wingo test]# 


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

glusterfs-3.6.0.36-1.el6rhs.x86_64


How reproducible:
=================

always


Steps to Reproduce:
===================
1. Create 4 node cluster
2. Create a volume
3. Mount a volume to the client
4. Create a directory test
5. create .snaps inside test
6. cp -rf /etc etc5 in .snaps
7. ls -la from test, should show .snaps
8. ls .snaps, should show etc5
9. Enable USS
10. ls -la from test, it shows .snaps

Actual results:
===============

It shows .snaps, which is now a virtual snapshot-directory


Expected results:
=================

Once the USS is enabled, virtual snapshot-directory should not be visible

Comment 2 Vijaikumar Mallikarjuna 2014-12-05 10:02:14 UTC
Upstream patch 'http://review.gluster.org/#/c/9120/' fixes the issue

Comment 3 Pavithra 2014-12-08 10:27:43 UTC
Hi Vijai,

I see this bug listed as a known issue in the known issues tracker bug for 3.0.3. Can you please fill out the doc text after changing the doc type to known issue?

Comment 5 Pavithra 2014-12-16 10:36:52 UTC
Hi Vijai,

Can you please review the edited doc text for technical accuracy and sign off?

Comment 6 Vijaikumar Mallikarjuna 2014-12-16 11:52:57 UTC
Doc-text looks good to me

Comment 7 Vijaikumar Mallikarjuna 2016-02-01 11:54:45 UTC
This bug will be fixed in 3.1.z. Bug# 1303593 filed to track this issue for 3.1.z.