[PATCH v2] smbtorture: Add smb2.maxfid

[Jeremy Allison]

On Wed, Jul 13, 2016 at 01:29:22PM -0700, Christof Schmitt wrote:
> On Wed, Jul 13, 2016 at 11:05:38AM -0700, Jeremy Allison wrote:
> > On Wed, Jul 13, 2016 at 10:54:59AM -0700, Christof Schmitt wrote:
> > > 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.
> > 
> > No, look at the torture_setting_int() calls in
> > source4/torture/basic/delaywrite.c to see how to add
> > a comment line tuneable.
> 
> Thank you. That is easy enough, see attached patch.
> 
> My point was that I would like to have the test fail when the specified
> limit cannot be reached, but the server limit is unknown in the selftest
> environment since it depends on the ulimit that is likely already set on
> the system.  Maybe the current approach is good enough for now.

LGTM. Pushed !