Bug 971 - options 'case sensitive' and 'preserve case' are mutually exclusive. hinders performance tuning on large directories
options 'case sensitive' and 'preserve case' are mutually exclusive. hinders ...
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.1
All Linux
: P3 normal
: none
Assigned To: Gerald (Jerry) Carter
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-14 08:10 UTC by Philipp Richter
Modified: 2005-08-24 10:19 UTC (History)
0 users

See Also:


Attachments
Fix for 'case sensitive' and 'preserve case' being mutually exclusive (1.17 KB, patch)
2004-01-14 08:11 UTC, Philipp Richter
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Richter 2004-01-14 08:10:11 UTC
After finding out that setting 'case sensitive' to 'yes' causes samba to read 
the whole directory on every opened file we tried to suppress this behaviour 
on a specific share. This share gets ~30000 files copied to (each ~7Kb) and as 
expected the performance degrades quickly (not filesystem depend!). We tried 
to use these parameters for the share: 
 
    case sensitive = yes 
    preserve case = no 
    short preserve case = no 
    mangle case = yes 
 
After following changes to the source (source/smbd/filename.c) the config 
shown above works as expected 
 
- 'preserve case' is ignored if 'case sensitive' is set. 
- after unignoring 'preserve case' the check if a path or 
  a file was not found had to be added. 
 
One filecopy from Windows to the Samba machine without the patch: ~1:30 hrs 
                                                      with patch: ~14min 
 
This problem exists in every testet Samba installation (2.2.8a, 3.0.1, HEAD)
Comment 1 Philipp Richter 2004-01-14 08:11:46 UTC
Created attachment 360 [details]
Fix for 'case sensitive' and 'preserve case' being mutually exclusive
Comment 2 Gerald (Jerry) Carter 2005-02-05 07:37:56 UTC
This has been reworked in the latest SAMBA_3_0 svn code so 
I'm not sure this report still applies.  Feel free to reopen it
if the issue still exists in revision 5140 or later.
Comment 3 Gerald (Jerry) Carter 2005-08-24 10:19:15 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.