Subject: Re: Parameterizing things in local.h

[Richard Sharpe]

Date: Thu, 09 Apr 1998 21:06:25 +1030
From: Mail Delivery Subsystem <Postmaster at internode.com.au>
Subject: Returned mail: Host unknown
To: sharpe at ns.aus.com

   ----- Transcript of session follows -----
554 <jeremy at java.netapp.com>... 550 Host unknown (Authoritative answer from
name server)

------- Received message follows ----

Return-Path: <sharpe at ns.aus.com>
Received: from ppp127.adelaide.on.net.au by wraith.internode.com.au
  (was once sendmail 5.83--+1.3.1+0.50/UA-5.23) with SMTP id AA20816
  for <jeremy at java.netapp.com> return <sharpe at ns.aus.com>;
  Thu, 9 Apr 1998 21:06:25 +1030
Message-Id: <3.0.5.32.19980409204438.0086bde0 at mail.adelaide.on.net>
X-Sender: ns at mail.adelaide.on.net
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Thu, 09 Apr 1998 20:44:38 +0900
To: jeremy at java.netapp.com
From: Richard Sharpe <sharpe at ns.aus.com>
Subject: Re: Parameterizing things in local.h
In-Reply-To: <199804090822.BAA00815 at java.netapp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:28 PM 4/9/98 +1000, Jeremy Allison wrote:
>Andrew Tridgell wrote:
>
>> yeah, but just upping MAX_OPEN_FILES (whether at runtime or compile
>> time) doesn't actually solve the problem. Many unixes have quite low
>> limits on the total number of file descriptors. If you run 3 or 4
>> clients each opening 1000 files then the global limit is reached and
>> smbd will fail. We have to have a way to "idle" file descriptors to
>> avoid the low limits that many unix systems have.
>
>Yes, but this runs into the oplock problem. We need
>to keep files open that are oplocked to have any
>*hope* of maintaining file consistancy when the
>commercial UNIX vendors (finally) add kernel level 
>oplock support (which I believe they will when MS has
>kicked them enough to be *really* scared - not
>just mildly scared like they are now). Of course
>Linux & FreeBSD will add it when we finally get
>motivated enough to code it ourselves :-).

[Deletia]

>Very few processes ever *use* that many fd's so
>keeping the open files as real UNIX fd's doesn't
>get to be that much of a drain on kernel resources,
>it's just that those processes that *do* need them
>transiently should be allowed to get them, without
>having to re-compile Samba to achieve it.

Hmmm, is this topical or what :-)

Just today I had to recompile Samba to increase MAX_OPEN_FILES from 100 to
200, because a customer is running a DOS based program that keeps lots of
open files.

I was concerned about doing this (on a RedHat 4.0 Linux system with a
2.0.27 kernel). 

I would have preferred that I be able to put in the smb.conf or the
smb.conf.%m a line saying:

  max files = 250

Then only those clients that need more open files need such a statement. It
just becomes one more thing that is malloc'd upon startup.

>Jeremy.
>

Regards
- -------
Richard Sharpe, sharpe at ns.aus.com, NIC-Handle:RJS96
NS Computer Software and Services P/L, 
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080, 
Linux, AIX, Digital UNIX, ULTRIX, SunOS, Samba, Apache, NetScape, ICSS,
Perl, C, C++ ...

------- Received message ends    ----


Regards
-------
Richard Sharpe, sharpe at ns.aus.com, NIC-Handle:RJS96
NS Computer Software and Services P/L, 
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080, 
Linux, AIX, Digital UNIX, ULTRIX, SunOS, Samba, Apache, NetScape, ICSS,
Perl, C, C++ ...