[PATCH v2] smbtorture: Add smb2.maxfid

[Christof Schmitt]

On Tue, Jul 12, 2016 at 04:26:31PM -0700, Jeremy Allison wrote:
> On Tue, Jul 12, 2016 at 04:13:02PM -0700, Christof Schmitt wrote:
> > On Tue, Jul 12, 2016 at 02:52:25PM -0700, Jeremy Allison wrote:
> > > On Tue, Jul 12, 2016 at 11:28:32AM -0700, Christof Schmitt wrote:
> > > > Here is a slightly updated version of the patch. The original version
> > > > did not close the file handle of the share directory. With the change to
> > > > close it early, the number of files to open should match the server
> > > > configuration (e.g. from 'max open files').
> > > 
> > > LGTM. What result did you get from Windows ?
> > 
> > In my initial tests with a Windows 8.1 system the maximum limit in the
> > test was not hit. See the attached patch that allocates a larger array
> > for the test.  With that change i hit a limit on the Windows system:
> > 
> > smbtorture 4.5.0pre1-DEVELOPERBUILD
> > Using seed 1468363827
> > time: 2016-07-12 15:50:27.818167
> > test: maxfid
> > time: 2016-07-12 15:50:27.819592
> > Creating subdirectories
> > Testing maximum number of open files
> > create of smb2_maxfid\262\262144 failed: NT_STATUS_INSUFFICIENT_RESOURCES
> > Maximum number of open files: 262144
> > Cleanup open files
> > time: 2016-07-12 16:09:08.740471
> > success: maxfid
> 
> Pushed, but we should probably make this a command line
> tunable eventually.

Thanks. I thought about making this a tunable, but i could not find a
good way to use that in the selftest environment. If the maximum number
of open files is limited by the hard ulimit -n setting, then selftest
cannot easily know about that. One option would be querying the ulimit
from selftest and assume that the same (or "max open files", whichever
is lower) applies to smbd, but that seems somewhat ugly.

Christof