Too many files are currently in use?

FYI, Samba Version 3.5.6 disregards the ulimit setting,

and sets its own Max open files to 16520.

 

not sure where you get 16520 though, different samba version perhaps?

 

 

Yes, different versions.  I was talking about Samba 3.5.6.

That's what I've been running on top of stock unRAID 4.5.6.

 

I have 3.5.6 running here in -beta3 and /proc/<pid>/limits reports 16424 for 'Max open files' on an smbd daemon, and 16404 for an nmbd daemon.  As long as the number is greater than 16384 there shouldn't be any Win7 issues.

FYI, Samba Version 3.5.6 disregards the ulimit setting,

and sets its own Max open files to 16520.

 

not sure where you get 16520 though, different samba version perhaps?

 

 

Yes, different versions.  I was talking about Samba 3.5.6.

That's what I've been running on top of stock unRAID 4.5.6.

 

 

 

I have 3.5.6 running here in -beta3 and /proc/<pid>/limits reports 16424 for 'Max open files' on an smbd daemon, and 16404 for an nmbd daemon.  As long as the number is greater than 16384 there shouldn't be any Win7 issues.

sysctl  fs.file-max

I see fs.file-max = 45116 on my older original Intel MB server on 4.6 unRAID (512 Meg of ram), and fs.file-max = 405400 on the newer C2SEE MB running 5.0b2 (with 4Gig of RAM)

Joe L.

I see fs.file-max = 45116 on my older original Intel MB server (512 Meg of ram), and fs.file-max = 405400 on the newer C2SEE MB running 5.0b2 (with 4Gig of RAM)

Joe L.

tomm@Develop:~# uname -a
Linux Develop 2.6.36.2-unRAID #3 SMP Mon Jan 3 01:42:06 MST 2011 i686 Intel(R) Atom(TM) CPU D510   @ 1.66GHz GenuineIntel GNU/Linux
tomm@Develop:~# sysctl fs.file-max
fs.file-max = 413644
tomm@Develop:~#

I'm just trying to decide whether to put the 4K-sector fix in as well 

With all the drama and confusiuon I see on the forums about the Advanced Format drives, this might cut down on a lot of the support requests because it would no longer be an issue.  The 4K drives that cannot be jumpered or made compatible would also work.  Drives that are already jumpered or are currently compatible would work without any changes and could be left alone.

If you are comfortable with your testing, I'd suggest that you go ahead and include it in the 4.6.1 release.

The only thing I fear with adding 4K sector stuff to a 4.6.1b1 (or 4.6.1rc1, however you want to name it) is that it will draw out the 4.6 series even further.  If 4K sector stuff works without an issue then great, but there might be stuff that shows its ugly head.

JoeL has a newer version of the preclear script to accommodate starting at sector 64 I believe, though I am not sure it has been tested.

I unfortunantely do not have any "advanced format" drives to test unRAID starting at sector 64.

The only thing I fear with adding 4K sector stuff to a 4.6.1b1 (or 4.6.1rc1, however you want to name it) is that it will draw out the 4.6 series even further.  If 4K sector stuff works without an issue then great, but there might be stuff that shows its ugly head.

 

JoeL has a newer version of the preclear script to accommodate starting at sector 64 I believe, though I am not sure it has been tested.

 

I unfortunantely do not have any "advanced format" drives to test unRAID starting at sector 64.

Right this is a tough call, but there are lots of people using 4.6 who won't want to switch to 5.0 until not only out of beta, but also running for a while.  In meantime these drives are going to become more common.  I guess the line will be drawn with "high capacity" drives which will require far more coding changes and probably not be supported in 4.X series.

Any chance that in the 4.6.1 of re-adding the external kernel modules for additional filesystems such as ext3 and ext4 as well as advanced power management that was briefly in the 4.6-rc series?

Right this is a tough call, but there are lots of people using 4.6 who won't want to switch to 5.0 until not only out of beta, but also running for a while.  In meantime these drives are going to become more common.  I guess the line will be drawn with "high capacity" drives which will require far more coding changes and probably not be supported in 4.X series.

While everyone feels the urge to move to 5.0, I agree that it needs to be stable for many of us before we commit it to production.  I will use 4.6 until 5.0 has some time on it and is out of Beta.  I will use 5.0 on a test server I have to get a feel for it and learn about it, but I don't have the time to work on new issues on 5.0 while it is in its infancy.  It's not that I don't care, it's just that I don't have a lot of spare time to commit to it.  My main reason for going to unRaid (I left WHS V1 and Vail in the dust) was I wanted a platform that would "just work".  unRaid does just that.

The only thing I fear [...] is that it will draw out the 4.6 series even further.

As far as I am concerned, he can keep the 4.x series going forever.

I don't understand all this eagerness to put an end something that's good and stable.

Will it give you a warm feeling if he bumps the version number to 7.0?

And what's new in 5.0 anyway? Just some web-page eye-candy. I couldn't care less.

I am not saying this to discourage the work on 5.0.  It's admirable and all.

But the 4.x series is still Limetech's flagship product, and may still be for quite some time to come.

(Remember, 5.0 beta was announced in late 2009...

Timeframe?  I wanted to release 5.0-beta1 simultaneous with 4.5-final, but it's going to take some more time.  But I do want to get it out before Christmas to give you guys something to experiment with in-between catching up with watching all those movies you have on your servers!

...and it is now 2011 as I'm writing this.)

Why was this thread moved?

It was a very valid discussion.

Back now.  Refer to your sig for explanation 

Is there a verdict on the too many files problem? I'm running 4.6 and experiencing the problem myself as a new user. I kept seeing things about setting the ulimit to 20000. Is this solution, and where would I add that command on my flash device? I checked the ulimit setting before I changed it and it was already set to 'unlimited'. Why would changing it to 20000 actually help?

For now the solution is to put the following line at the top of the go script on your flash ahead of the emhttp line:

ulimit -n 16404

Limetech is working on a permanent fix for this.  There will probably be a 4.6.1 release with this fix according to Limetech.

Is there a verdict on the too many files problem?

I'm running 4.6 and experiencing the problem myself as a new user. I kept seeing things about setting the ulimit to 20000. Is this solution, and where would I add that command on my flash device?

I checked the ulimit setting before I changed it and it was already set to 'unlimited'. Why would changing it to 20000 actually help?

To add the line you can just type this following line in a telnet session. It will add the ulimit for you to your "go" script.  Then all you'll need to do is reboot.  

sed -i "sX^/usr/local/sbin/emhttpXulimit -n 16404;/usr/local/sbin/emhttpX" /boot/config/go

(easiest is to cut and paste it in a telnet window)

After adding the line, you'll need to reboot.

The above "sed" (stream edit) line will change the line in the /boot/config/go script invoking emhttp

from

/usr/local/sbin/emhttp &

to

ulimit -n 16404;/usr/local/sbin/emhttp &

Joe L.

Cool, thanks Joe.

bumping up a older topic...

I think I've seemed to hit this problem too but the above solution doesn't seem to fix it.

I have a single torrent that consists of about 3600 files. Whenever this torrent starts, after a few seconds, uTorrent that's running on the PC will show "disk overload 100%". Seems like the unRaid server can't handle that many open files at once.

There are no entries in syslog, but when I type "lsof -u root | wc -l" right when I start the torrent, I can see the number increase from about 1052 (i have some other torrents running) to about 1370 or so, which is when uTorrent will give me the disk overload error. If I don't start this torrent, all my other torrents are fine.

I've applied the above, but when I open a telnet session via putty and type in "ulimit -n" it reports 1024 (but i think this is normal since this is spawning another session?).

Is there anyway to hardcode the new value somewhere ?