Bug 1126837

Summary:	Performance degradation in SMB over VFS when compared to FUSE
Product:	[Community] GlusterFS	Reporter:	Poornima G <pgurusid>
Component:	libgfapi	Assignee:	Poornima G <pgurusid>
Status:	CLOSED EOL	QA Contact:	Sudhir D <sdharane>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.5.2	CC:	bugs
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-17 15:58:07 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:

Description Poornima G 2014-08-05 12:06:12 UTC

Description of problem:
Directory listing under CIFS is very slow

Customer has tried in both glusterfs fuse and SMB:

Under glusterfs a ls -ltR to a specific directory took 1.5 seconds and 53 under cifs.

and in other test

Glusterfs: 0.9s
Samba share to local filesystem: 3.8s
Samba share to gluster filesystem: 18s

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Poornima G 2014-08-05 12:08:17 UTC

The getxattrs are being called for user.dosattributes. If the customer is not
interested in using the dos attributes which are: hidden, read-only, system and archive. (Thats the one which shows on the first tab of the file properties tab in Windows.) then they can disable it and see good performance improvement with listing of the directories.

NOTE: We have not tested this workaround and listed its impact. If it is a POC on the customer side and they are willing to try , you may suggest this.

steps:
1. Change yes to no in "store dos attributes = yes" in /etc/samba/rhs-samba.conf.
2. service smb restart.
3. Perform the same test again from the client.

But the lookup are still huge in number 5000 for 3000 lookups, where as in FUSE it is ~16 lookups.

Comment 2 Niels de Vos 2016-06-17 15:58:07 UTC

This bug is getting closed because the 3.5 is marked End-Of-Life. There will be no further updates to this version. Please open a new bug against a version that still receives bugfixes if you are still facing this issue in a more current release.