samba - Feb 2002 - Will samba work on Linux/486 with heavy swapping?

I'm very sorry about posting HTML. I know better then that and should have
double checked my defaults. I'm reposting this hoping someone

    Is there a known bug that samba has on older machines in low memory
environments? I have set up a 486 with 24Mb of memory with RedHat 7.1. I set
it up to run dhcpd, xinetd, and samba. Samba was not run through xinetd. The
samba server had a tendency to crash the machine if a large upload was sent
to it. Occasionally, it wouldn't crash, but windows would error and stop
uploading. No problems were ever experienced while downloading from samba.
As RH 7.1 used an old version of samba (2.0.xxx), I upgraded to the latest
available. I also tried it with a newer kernel and various custom kernels. I
still got the same result: samba crashing the machine on heavy uploads. I
later tried using 3com's own driver for my NIC card, as I thought the
kernel's included 3com vortex driver might be at fault. This did not help.
    Recently, I installed an LFS system, book 3.1, and put up dhcp, xinetd,
and samba version 2.2.3a. After getting everything working, I got the same
behavior: system crash on a large upload. This is with a completely
independant install, LFS instead of RH, and I am still getting this error.
    My guesses are that maybe samba doesn't like the extreme low mem
conditions on my box; it uses almost all physical memory at idle, but there
is plentiful swap.
Maybe this is being caused by the drives being too slow, possibly coupled
with the fact that there is heavy swapping. (The old motherboard doesn't do
DMA IDE).
Maybe this is a misconfigured samba.
Maybe this is not a samba problem. (Although I did do limited use of FTP
under RH and never had a problem).
    I would appreciate any way to narrow down what this might be or any
other ideas what it might be. I've seen another reference in the archives in
2000 of a guy that had a machine that timed out alot, but nothing about his
server crashing. There was no news of how or if it was resolved though. I'd
really like this 486 a samba server. Am I asking too much from old hardware?


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

TJ wrote:
> 
>     Is there a known bug that samba has on older machines in low memory
> environments? I have set up a 486 with 24Mb of memory with RedHat 7.1. I
set
> it up to run dhcpd, xinetd, and samba. Samba was not run through xinetd.
The
> samba server had a tendency to crash the machine if a large upload was sent
> to it.
When you say 'crash the machine' do you mean abort samba or actually
cause an
operating system panic?  If you are getting panics, you may need to upgrade
to a more recent version of the kernel. I track linux kernel development on
my home machine and there has been some comments in the change logs about
file system problems being fixed recently. Red Hat's put out at least three
kernel upgrades since the release of 7.1.

I also have a 486 that runs SaMBa (now 2.2.3a) with 32 MB running RH 7.2 with
patches. I did a custom kernel to clean out unused features and make more
memory available. It serves profiles to a small number of Win9x boxes with
roving profiles, so there is quite a bit of upload when the kids log-off. 
I'm not sure that it is as badly stressed as your box is. I can run X on it 
and use xosview to monitor its stress levels (X is pretty stressful by itself!) 
and not had it or SaMBa crash.

mtew@cds.duke.edu

> OK. That's a 20:1 swap/real memory ratio!
> Conventional wisdom is that 2:1
> is the lowest usable value with 4-5:1 being optimum.
> If you need more than
> that, you're so badly overloading the machine that
> it becomes pretty useless.
>
> Since you didn't panic at the mention of building a
> kernel, I suspect you've
> done it at least once...
> 
> You mentioned putting a terminal on the serial port
> and getting a report on
> a kernel page fault. If you can get a stack dump and
> trace the problem back
> to the point where someone jumped off into
> never-never land, there's a good
> chance you'll be able to get the problem fixed.
> 
> The fact that you are using RAID is significant. I
> started to 'fine tooth'
> that code and was not entirely happy with what I
> found. They are going to 
> have to redesign that sub-system at least once more
> to get it completely
> right. The on-disk data structures are not what they
> should be. However, 
> it works well enough as it stands to be useful.
> Their error recovery code
> was quite buggy, like most error recovery code is.
> 
> I'm less sure of this than I might be, but I think
> RAID puts a fairly
> heavy load on memory. It ties up a fair number of
> 'chunk size' buffers
> for fairly long periods of time. Normally, a large
> chunk size improves
> performance, but I'd guess that a low memory
> condition would change that.
> On the other hand, I'm not certain that 'chunk size'
> is relevant to RAID 1.
> I know it has a significant impact on RAID 0 and
> RAID 4/5.
> 
> Are you swapping to a RAID? This is generally not a
> good idea. The only
> advantage is that your system doesn't crash if you
> lose your swap drive,
> but the performance costs are quite high; a 30%
> reduction in thruput is 
> typical. On my production machines, I RAID 1'ed the
> '/boot'. '/' and
> '/home' partitions but did not use RAID on the swap
> partitions. If I
> loose a drive, the machine goes down and comes back
> up automatically 
> without the swap partition on the bad drive. Not
> great, but it let's
> me know that the drive is dead! In your case, I'd
> trade the low 
> probability hard drive for the high probability
> kernel panic.
> 
> From a RH 7.2 (2.4.9-21) system:
> dir /proc/sys/vm
> bdflush    kswapd         min-readahead     
> page-cluster
> buffermem  max_map_count  overcommit_memory 
> pagetable_cache
> freepages  max-readahead  pagecache         
> static_inactive_target
> 
> So it's there in the stock kernel. When you say it's
> not there on
> your system, exactly how much of it isn't there?
> 
> I believe you can also set vm.freepages in
> /etc/sysctl.conf to the
> same effect. If you built a kernel without sysctl,
> that would explain
> why you don't see the file.
> 
> kernel.org is the definitive Linux kernel source. I
> mirror a lot of that
> site daily to one of my home machines. I do NOT
> really have time to look
> at much of it though. I've been focusing more on
> SaMBa lately.
> 
> Red Hat does a LOT of testing on the kernel before
> they put their name on
> it. Even the RawHide stuff gets some testing before
> it's posted. They have
> a whole series of patches they apply. That's what
> the second version number
> is about. They send their stuff back to Linus and
> company so eventually
> it either gets into the kernel.org distribution, or
> the problem is fixed
> some other way. I've seen discussion of this on the
> mailing lists.
A little more info: The drive I lost was a 45GbIBM
75GXP. I believe the problems were due to the drive
more then anything, although you're definitely right
that they need to be kept cool. The same drive failed
twice, the second time a low level format didn't help
it, so I had to RMA it. In the meen time, I bought a
new 60Gb 60GXP. I run RAID 1 on both the 75GXP and
60GXP. Because one drive is 15 gigs bigger, I have 15
gigs to play with. That 15 gigs is a 4 gig / partition
and 500 megs of swap.. I use such a big swap simply
because I have so much useless disk space. Since the
linux install is almost minimal, it actually uses less
then 1 Gb. The swap is not in the RAID, I read all
about why not to do that when I was reading about how
to set up RAID. You're right about heavy mem usage.
With a stock kernel (very bloated) the machine used
99% of the memory and was already swapping just after
booting and starting services (nothing major, no
smbd).
I almost always compile my own kernels as I like them
small and I don't like heavy module usage. I just
patched my 2.4.16 source to 2.4.18 (I made sure to
apply the 2.4.17 patch first) and began a new compile
hoping maybe some bugs were fixed. I haven't tried it
yet, though. Also, I made sure to enable sysctl and
I'm anxious to see if /proc/sys/vm/freepages exists
after booting with the new kernel. The old one has
some of the files you are listing, so I feel sysctl
was turned on. I am thinking of emailing Rik van Riel
and asking about the current state of freepages usage.
He said on the kernel mailing list in 2001 that 2.4
didn't use freepages, but he would look into
implememnting some way to control it again. The docs
in the kernel source (Documentation/sysctl/vm.txt I
think) show it still as valid, but those docs claim
they are for 2.2 kernels! That shouldn't be in the 2.4
source.
Sorry for the misunderstanding, I didn't attach
anything to the serial port, I just ran a VGA monitor
and keyboard to it. That's console for me. I'm not a
complete newbie, but the sysctl stuff is new to me and
I'm learning about it. Also, I don't know how to use
the kernel logs and error msgs to track down what
caused the problem. How can I get a stack dump? Is
this the error msg and all that the kernel dumps to
console and log when it panics?
I tried reproducing the error (copying a file to the
linux box via smb) with the RAID 1 array unmounted and
turned off (raidstop /dev/md0) and I still got the
error, so I'm pretty sure it isn't due to my RAID use.
After I get the new kernel up, I'll stress the machine
using smb but no RAID (It has a fit when the machine
crashes and feels it necessary to rebuild the array
after every crash.. very annoying). Next, if it
exists, I'll try to increase the freepages and see if
that does anything. If it's stable, I'll crank up RAID
and try stressing it some more while serving the RAID
partition. If it's not stable, I'll start looking
though van Riel's patches to the kernel or RH's
latest.
I do not like redhat much because they don't like
putting up tar.gz files, just srpm's. This is a pain
for me as I am unwilling to install rpm, so I must
boot my old RH partiton when I want to use rpm. 

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

References: <001d01c1bd83$ff37d8a0$8ced91cc@lfs>
<3C7A5D2A.F1983CEB@cds.duke.edu>
<005c01c1be42$4efb5e20$83ed91cc@lfs>
<3C7AB27F.2FC722E7@cds.duke.edu>
<000c01c1be63$79208a60$83ed91cc@lfs>
<3C7BAEEC.3AC5975F@cds.duke.edu>
<000b01c1bf56$76d8d8e0$9bed91cc@lfs>

Uh, TJ, About that previous message from me that you posted to the list --
Please warn me when you intend to do that. I was a bit more blunt in my
problem descriptions to you than I would have been to a public forum. I
hereby apologize to anybody that might have been offended by my overly
direct remarks.

As for your problem, let me summarize:

1) You are not running a standard Red Hat kernel.
2) You were getting kernel panics and are now getting other kernel errors.
3) You are seeing a 400KB jump in memory use from 700KB free to 300KB free.
   The next step would take you to -100KB free. Not good.

I conclude:

1) This is not a SaMBa problem, or if it is, it is one compounded by a 
   kernel problem. The kernel problem should be addressed first.
2) A Linux bug report directly to kernel.org is in order.

Other comments:

RPMs have their place. The source RPMs almost always include .tar.bz2 packed
distributions of the original packages, patches, build scripts, dependency 
information and more so the binary distributions can be rebuilt. The binary 
RPMs are intended to be more compact and contain only the information needed
to instal and remove the package. They perform their job very well, but are
intended to supplement, not replace the original distributions.