Bug 6863 - low performance when user is not file owner
Summary: low performance when user is not file owner
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.2.14
Hardware: x86 Linux
: P3 normal
Target Milestone: ---
Assignee: Volker Lendecke
QA Contact: Samba QA Contact
Depends on:
Reported: 2009-10-31 15:39 UTC by Plamen Krastev
Modified: 2010-02-14 04:51 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Plamen Krastev 2009-10-31 15:39:53 UTC
Samba acts like PDC for 3 windows 2003 R2 SP2 clients, users from a windows machine authenticate with his own login and password and work with files from samba share. When the owner of the files works with them everythings is normal, but when other user, not file owner, but that have permissions to access that files work with them.... everything is many many times slower.
( files permissions are 777 )
Comment 1 Volker Lendecke 2010-02-07 09:12:14 UTC
Please describe in a lot more detail what exactly is slower.


Comment 2 Plamen Krastev 2010-02-11 11:25:24 UTC
Ok, I'll try to describe the problem more accurate.

We run software that uses btrieve and dbf databases. The DB files are located on a samba share.
We made some checks and it turns out that there are many reads from the database files. Mostly small reads for 2 bytes.
Here I should say that the DB files have linux perms of 0777 and a group named "DBusers" for example.
The windows workstations are 2003 R2 SP2 and are up to date.
When we log in the domain with the user, which is the owner of the DB files and run the software, everything seems to work normal (as expected).
The problem comes when another user, not the owner of the DB files, but belonging to DBusers group, logs in to the domain and start the software. 
The software works normal with the exception that it is very very slow.
When the software is run with the owner, one report from the software executes for about 5 seconds and when another user starts the software and run a report it takes about 5-6 minutes .... huge difference.
One thing we noticed with Process Monitor is when we run report with the owner every read from a file takes about 0.00003 sec and when it runs with the other user (slow) it takes 0.00050 sec. 
As you can imagine there are alot of reads.
One more thing to say here. When the software runs from a samba which is not DC, just a simple share with "share level security" everything seems to be fine.
We've tried to setup one Windows Server 2003 R2 SP2 as a DC and simulate the same problem, but it's not a issue there.
The filesystem on the Linux DC (where the samba is) is ext4 mounted with options "noatime" and "acl". The "acl" is needed so we can use inherit of permissions in windows.
The Samba version is 3.2.14.

I hope I spread more lights on the problem.
Thank you for your efforts.
Comment 3 Volker Lendecke 2010-02-14 04:51:35 UTC
This very much sounds like an oplock problem, not a permission problem. I've had *exactly* this same symptom at a customer site. They said that the database stored on Windows was fast, but once they store it on Samba it was slow. The difference was that their tests on Windows were always done with a single user only, so the client got an oplock which made things fast. But on Samba it was multi-user access so the oplock was gone. When that happens the access starts to crawl. There's nothing you can do about it.

You can test this the following way: Open the db in "fast" mode, go to a different computer and copy the database somewhere else with explorer. At that moment the oplock is gone, and the "fast" mode will have turned to "slow" mode.

To really rule out the permission problem: Shut down all applications using the db, and *ONLY* open with a previous slow one. This should be fast as long as it is alone on the db.

Essentially, access should be fast as long as you see EXCLUSIVE as oplock type in smbstatus.

Marking this bug as invalid, I don't think this is a Samba bug. Please re-open if the oplock tests fails to show any success and you really see it as a permission problem.