Bug 1544 - directory listing very slow for "hide unreadable"
directory listing very slow for "hide unreadable"
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.1
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-20 04:36 UTC by philipp.marek
Modified: 2009-04-30 07:07 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description philipp.marek 2004-07-20 04:36:14 UTC
-- our setup is as follows:

"hide unreadable" is turned on.
we have a share "home", which goes to /home.
There are several hundred directories, with all but four belonging to individual
users, and the access masks are 0700.
We don't use ACL's, just go along with the unix permissions.


-- the problem is:
If you try to list this directory smbd is very busy and takes a long time to
check the visible files.


-- analysis
If you go to a subdirectory, and put a symlink there, which goes back to /home,
directory listing is fast as usual.

strace()ing smbd shows that smbd reads (and locks) smbpasswd and group_mapping
*for each entry*.

reading the source I see that for each entry (dummy) acls are created (one for
the parent directory, and one for the entry); and that creation takes some time,
I believe.


For our setup I changed the function user_can_read_file:

smbd/dir.c
@@-714,6 +714,9 @@
     if (!fsp)
              return FALSE;

+    close_file(fsp, True);
+    return access(name, R_OK);
+
     /* Get NT ACL -allocated in main loop talloc context. No free needed here. */
     sd_size = SMB_VFS_FGET_NT_ACL(fsp, fsp->fd,

and user_can_read_file got the same, except for the W_OK instead of R_OK.


-- reproduction recipe
generate some hundred users, give them directories with mask 0700, and get a
directory listing.


-- conclusion/solution
1) maybe the smbpasswd file could be cached in some kind of hash, so that it
needn't be parsed for each entry.
2) maybe an "empty" acl can be prepared, where just (at known positions) the
SID's are changed before being used, instead of building one from the start up.
3) how about a compile option to disable acl support (I believe 2.2 had this),
which would speed up such operations?
4) any other ideas?


Thank you very much!
Comment 1 Gerald (Jerry) Carter 2005-02-07 10:25:20 UTC
please test 3.0.11 and reopen if the bug still exists.
Comment 2 Gerald (Jerry) Carter 2005-08-24 10:22:53 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 3 Gunnar H. 2009-04-29 11:41:30 UTC
This Problem still exists in v3.0.24 (Part of SLES 10) and even in the newest 3.0.34 smbd Binary from samba.org(In reply to comment #1)

Comment 4 Björn Jacke 2009-04-30 07:07:28 UTC
sorry, but 3.0 will only see security fixes. Can you please test with latest 3.2 or even better with the latest 3.3 release? There has been some caching of uid/gid lookups been added - also to speed up "hide unreadable". Please report back if 3.2/3.3 fixes the problem for you. Thanks!