samba - Jan 2001 - Proposed patch for Samba-2.0.7 to allow Solaris open more than 1014 (or rlim_fd_max) files

I would like to submit the following patch to source/lib/util.c to allow
Samba under Solaris to open more than 1014 files -- or whatever the kernel
variable rlim_fd_max is set to.

A little background:
We use Samba to provide Windows clients a way to access ClearCase VOBs
(versioned object bases) hosted by Solaris servers. One limitation has been
that smbd could only open (rlim_fd_max - 10) files. It isn't a good idea to
set rlim_fd_max above 1024 because a higher value will break any system that
uses the select() system call. Solaris 7 and 8 provide a way around this but
it requires that the affected application(s) be recompiled as a 64-bit
application. However, it isn't always possible to get applications
recompiled
as 64 bit.

This presents a problems because ClearCase will often want to open more than
1014 files. You can change a setting in ClearCase to reduce the number of
files that can be opened at once but this doesn't always solve the problem.

util.c calls setrlimit to raise the soft limit (rlim_fd_cur) to the hard limit
(rlim_fd_max). setrlimit can also raise the hard limit provided the effective
userid is root. smbd and nmbd usually run as root.

This avoids the need to change rlim_fd_max and break programs that use
select(). It only changes hard limit for smbd/nmbd processes.

This change would allow you to specify any value for "max open files
=".

To get the full benefit, you will also need to either

a) compile with sfio (which requires some additional changes to
   source/include/smb.h and source/include/config.h -- from David Boyce
   <dsb@world.std.com) 

OR

b) compile Samba as a 64-bit application

The reason for this is that smbd uses fopen to open the machine account (mac)
file. fopen without sfio or in a 32-bit compilation environment is limited to
256 file descriptors. If an smbd process has > 256 files but < 1014
(rlim_fd_max) files open it can still fail to open the machine account file.

If this patch is acceptable, I can probably provide changes for configure to
handle the changes to source/include/smb.h and source/include/config.h. The
fix for smb.h is not necessary in the Samba 2.2 stream.

--- samba-2.0.7/source/lib/util.c.~1~	Tue Apr 25 19:06:53 2000
+++ samba-2.0.7/source/lib/util.c	Tue Jan 23 08:00:48 2001
@@ -3012,6 +3012,18 @@
 	 * which always returns RLIM_INFINITY for rlp.rlim_max.
 	 */
 
+        if ( geteuid() == 0 ) {
+          
+          if ( rlp.rlim_max < requested_max ) {
+            rlp.rlim_max = requested_max;
+          }
+
+          if(setrlimit(RLIMIT_NOFILE, &rlp)) {
+            DEBUG(0,("set_maxfiles: setrlimit for RLIMIT_NOFILE for %d max
files failed with error %s\n",
+                     (int)rlp.rlim_max, strerror(errno) ));
+          }
+        }
+
 	saved_current_limit = rlp.rlim_cur = MIN(requested_max,rlp.rlim_max);
 
 	if(setrlimit(RLIMIT_NOFILE, &rlp)) {

-- 
Eric M. Boehm                               boehm@nortelnetworks.com

Eric Boehm wrote:
> I would like to submit the following patch to source/lib/util.c to allow
> Samba under Solaris to open more than 1014 files -- or whatever the kernel
> variable rlim_fd_max is set to.
> The reason for this is that smbd uses fopen to open the machine account
(mac)
> file. fopen without sfio or in a 32-bit compilation environment is limited
to
> 256 file descriptors. 
	Fopen is used numerous times, via sys_fopen,
	or I'd suggest we just not use fopen at all...


--dave
--
David Collier-Brown,           | Always do right. This will gratify 
Performance & Engineering Team | some people and astonish the rest.
Americas Customer Engineering  |                      -- Mark Twain
(905) 415-2849                 | davecb@canada.sun.com

At 03:10 PM 1/24/01 -0500, David Collier-Brown wrote:
>Eric Boehm wrote:
> > I would like to submit the following patch to source/lib/util.c to
allow
> > Samba under Solaris to open more than 1014 files -- or whatever the
kernel
> > variable rlim_fd_max is set to.
>
> > The reason for this is that smbd uses fopen to open the machine
account
> (mac)
> > file. fopen without sfio or in a 32-bit compilation environment is 
> limited to
> > 256 file descriptors.
>
>         Fopen is used numerous times, via sys_fopen,
>         or I'd suggest we just not use fopen at all...
Yes, when I last checked two years ago sys_fopen() was used in ~56 places. 
Which is unfortunate as it leads to a subtle bug but I don't think any 
Samba developer is so bored as to rewrite all of Samba to use low-level IO. 
It's easier to link with sfio or build in 64-bit mode and solve the problem 
that way, as Eric says. BUT! The point of his message was orthogonal to 
fopen(), sys_fopen(), and sfio. He mentioned them only in passing and I'd 
hate to see his thread get sidetracked on that topic.

The point of the patch is to allow Samba to raise the hard fd limit on 
systems which allow it and when appropriate privileges are held. This gives 
a new degree of freedom to the administrator and allows for a significant 
performance enhancement in some uses (specifically with ClearCase). I don't 
see any downside to it; if the OS refuses to allow the hard limit to be 
raised it just falls back to existing behavior. The default behavior 
remains unchanged but now, if you explicitly ask for a feature and the 
underlying OS supports it, you're no longer artificially prevented from 
getting at it - and that seems good.

-David Boyce

> To get the full benefit, you will also need to either
> 
> a) compile with sfio (which requires some additional changes to
>    source/include/smb.h and source/include/config.h -- from David Boyce
>    <dsb@world.std.com)
Compiling with sfio doesn't solve all the problems. The remaining
problem is that we don't know if library functions called by SAMBA call
fopen and company. Linking with binary compatibility shim doesn't help
as it would presumably suffer from the very same deficiency (or won't be
binary compatible).
> The reason for this is that smbd uses fopen to open the machine account
(mac)
> file. fopen without sfio or in a 32-bit compilation environment is limited
to
> 256 file descriptors. If an smbd process has > 256 files but < 1014
> (rlim_fd_max) files open it can still fail to open the machine account
file.
This is not 100% correct. It breaks when open(2) returns number larger
than 255, not when you have more than 256 files opened. See my
http://lists.samba.org/pipermail/samba-ntdom/1999-August/019940.html for
further information and a possible workaround.
> If this patch is acceptable,
I should also recommend -DUSE_POLL and -DFD_SETSIZE=2400 (or something),
-DUSE_POLL effectively prevents SAMBA from using select (which is btw
very similar front-end to poll anyway) and FD_SETSIZE scales up
structures used by SAMBA itself. BTW, USE_POLL code read "struct pollfd
pfd[256];" 256? Well, it means that we won't poll more that 256
descriptors at the same time, not that we can't have more files
opened... But it might feel better to declare FD_SETSIZE large... Or
alloca maxfd structures

Cheers. Andy.

At 11:56 PM 1/25/01 +0100, Andy Polyakov wrote:
>Compiling with sfio doesn't solve all the problems. The remaining
>problem is that we don't know if library functions called by SAMBA call
>fopen and company. Linking with binary compatibility shim doesn't help
>as it would presumably suffer from the very same deficiency (or won't be
>binary compatible).
Please remember, as mentioned before, that this whole stdio/sfio/MAX_OPEN 
thing is a sidetrack from the real (setrlimit) discussion.
> > The reason for this is that smbd uses fopen to open the machine
account
> (mac)
> > file. fopen without sfio or in a 32-bit compilation environment is 
> limited to
> > 256 file descriptors. If an smbd process has > 256 files but <
1014
> > (rlim_fd_max) files open it can still fail to open the machine account
> file.
>
>This is not 100% correct. It breaks when open(2) returns number larger
>than 255, not when you have more than 256 files opened.
Since open(2) is guaranteed to always return the lowest available file 
descriptor, this is a distinction without a difference IMHO (aside from the 
255/256 off-by-one error).
>See my
>http://lists.samba.org/pipermail/samba-ntdom/1999-August/019940.html for
>further information and a possible workaround.
This is a cute hack ... any idea why it didn't get rolled in? Was it just 
overlooked or did someone have a problem with it? I wish it was in there now.
> > If this patch is acceptable,
>
>I should also recommend -DUSE_POLL and -DFD_SETSIZE=2400 (or something),
>-DUSE_POLL effectively prevents SAMBA from using select (which is btw
>very similar front-end to poll anyway) and FD_SETSIZE scales up
>structures used by SAMBA itself. BTW, USE_POLL code read "struct pollfd
>pfd[256];" 256? Well, it means that we won't poll more that 256
>descriptors at the same time, not that we can't have more files
>opened... But it might feel better to declare FD_SETSIZE large... Or
>alloca maxfd structures
Do you mean HAVE_POLL? I don't see USE_POLL anywhere. HAVE_POLL is set by 
default on systems that have it; unfortunately I see no place where Samba 
looks at HAVE_POLL or uses poll(). The sys_select() function would be the 
obvious candidate but it doesn't, unless I'm missing some subtle macro. 
This is in current CVS 2.2.

-David Boyce

On Wed, 24 Jan 2001, Eric Boehm wrote:
> I would like to submit the following patch to source/lib/util.c to allow
> Samba under Solaris to open more than 1014 files -- or whatever the kernel
> variable rlim_fd_max is set to.
>
The patch works fine for me. When will the patch be included into CVS?

I've been working for a configure.in patch to include the sfio library
into the standard distribution.

If you have any ideas let me know.

Regards,
Gerhard Wiesinger

Gerhard Wiesinger writes:
> > I would like to submit the following patch to source/lib/util.c to
allow
> > Samba under Solaris to open more than 1014 files -- or whatever the
kernel
> > variable rlim_fd_max is set to.
> 
> The patch works fine for me. When will the patch be included into CVS?
OK - since there are multiple reports of it actually working, I
can probably merge it in to HEAD.  Hopefully Jeremy will pick it
up for the next 2.2 release.


Tim.

On Fri, 2 Feb 2001, Tim Potter wrote:
> Gerhard Wiesinger writes:
> 
> > > I would like to submit the following patch to source/lib/util.c
to allow
> > > Samba under Solaris to open more than 1014 files -- or whatever
the kernel
> > > variable rlim_fd_max is set to.
> > 
> > The patch works fine for me. When will the patch be included into CVS?
> 
> OK - since there are multiple reports of it actually working, I
> can probably merge it in to HEAD.  Hopefully Jeremy will pick it
> up for the next 2.2 release.
> 
Can you integrate it into the 2.0.7 source tree too?

BTW: I tested it on Suse Linux 7.0 (Kernel 2.2.16) and had the following
limitations with the patch.

I did with bash:
   echo 16384 > /proc/sys/fs/file-max
   echo 30000 > /proc/sys/fs/inode-max
works well.

Setting the rlimit works until the following:
  rlp.rlim_max = 1048576; // Works on Linux 2.2.16
  rlp.rlim_max = 1048577; // Operation not permitted on Linux 2.2.16

So rlp.rlim_max = RLIM_INFINITY; does not work on Linux 2.2.16.

So we could try infinity and when it does not work try this limit.

Regards,
Gerhard Wiesinger

On Thu, 19 Apr 2001 06:31:03 Gerhard Wiesinger wrote:
> 
> Why was the rlimit patch from Eric not integrated into 2.0.8?
2.0.8 was a security release only.  with a minor exceptions.





Cheers, jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com/  VA Linux Systems   gcarter@valinux.com
       http://www.samba.org/       SAMBA Team          jerry@samba.org
       http://www.plainjoe.org/                     jerry@plainjoe.org

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )

On Fri, 2 Feb 2001, Gerhard Wiesinger wrote:
> On Fri, 2 Feb 2001, Tim Potter wrote:
>
> > Gerhard Wiesinger writes:
> >
> > > > I would like to submit the following patch to
source/lib/util.c to allow
> > > > Samba under Solaris to open more than 1014 files -- or
whatever the kernel
> > > > variable rlim_fd_max is set to.
> > >
> > > The patch works fine for me. When will the patch be included into
CVS?
> >
> > OK - since there are multiple reports of it actually working, I
> > can probably merge it in to HEAD.  Hopefully Jeremy will pick it
> > up for the next 2.2 release.
> >
>
> Can you integrate it into the 2.0.7 source tree too?
>
> BTW: I tested it on Suse Linux 7.0 (Kernel 2.2.16) and had the following
> limitations with the patch.
>
> I did with bash:
>    echo 16384 > /proc/sys/fs/file-max
>    echo 30000 > /proc/sys/fs/inode-max
> works well.
>
> Setting the rlimit works until the following:
>   rlp.rlim_max = 1048576; // Works on Linux 2.2.16
>   rlp.rlim_max = 1048577; // Operation not permitted on Linux 2.2.16
>
> So rlp.rlim_max = RLIM_INFINITY; does not work on Linux 2.2.16.
>
> So we could try infinity and when it does not work try this limit.
>
Why was the rlimit patch from Eric not integrated into 2.0.8?

Ciao,
Gerhard

On Thu, Apr 19, 2001 at 01:31:03PM +0200, Gerhard Wiesinger
wrote:
> On Fri, 2 Feb 2001, Gerhard Wiesinger wrote:
> 
> Why was the rlimit patch from Eric not integrated into 2.0.8?
Because 2.0.8 was a security bugfix *only*. No new features
for the sake of stability. 2.2 includes this fix.

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------

On Thu, 19 Apr 2001, Gerald Carter wrote:
> On Thu, 19 Apr 2001 06:31:03 Gerhard Wiesinger wrote:
> >
> > Why was the rlimit patch from Eric not integrated into 2.0.8?
>
> 2.0.8 was a security release only.  with a minor exceptions.
I should also add the 2.0 is no longer being developed.  All efforts
are focuesed on HEAD and 2.2






jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com/  VA Linux Systems   gcarter@valinux.com
       http://www.samba.org/       SAMBA Team          jerry@samba.org
       http://www.plainjoe.org/                     jerry@plainjoe.org

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )