Barziya

Did you put the above line in your "go" script, and then reboot? If so, then the avahi daemon will not be started at boot, so how can it still spam your syslog?

This just struck me: Do you even have any Apple computers on your network? (Do you even need Avahi?) If not, then just a single line in your "go" script will fix all this for you: for i in /etc/rc.d/rc.avahi* ;do :>$i ;done

Only the whole list of changes in the Release Notes, from RC14 all the way to 5.0-final. For one example, around RC14 a bug in reiserfs was discovered that could lead to data loss. But if such things don't bother you, then you'll be OK.

I'm a little confused. I see a file "/var/log/syslog" that grows... am I not looking in the right place? You are looking in the right place. What are you confused about? Well, since "/var/log/syslog" resides on the flash drive... Wrong. unRAID's whole directory structure resides in RAM. Only what's mounted on the /boot/ directory is actually your flash drive.

Still, don't modify the syslog. (And, not through crond.) The syslog priority levels, in ascending order are: debug, info, notice, warning, error, emerg. Stock unRAID uses the highest log level -- debug -- logs everything. So you could lower the log level with something like this: mv /etc/syslog.conf /etc/syslog.conf.bak echo '*.info -/var/log/syslog' >/etc/syslog.conf /etc/rc.d/rc.syslog restart Is the syslog still getting spammed? If yes, try lowering some more: echo '*.notice -/var/log/syslog' >/etc/syslog.conf /etc/rc.d/rc.syslog restart ...etc. While the above may help you, it is still better to deal with the offending program's settings (avahi-daemon?), rather than messing with the syslogd conf settings.

I agree, although I have no idea on how to adjust the log level for the syslogd. I didn't mean the syslogd config, I meant the avahi-daemon config, wherever that is. (I don't use avahi so I can't help you with that.) I'm a little confused. I see a file "/var/log/syslog" that grows... am I not looking in the right place? You are looking in the right place. What are you confused about?

Wake me up when the Subject line says "$150 WD Red 4TB"

It would have been a great feature if TeraCopy had the option to save checksum files alongside whatever files it copied. That would save us the huge time waste to read a BIG file twice -- once when creating a checksum file for it, and a second time when copying that file to the server. If you are copying from a *nux machine, then you can accomplish the whole thing in a single pass with a tee command in a pipe. I haven't found any nice GUI with such functionality for Windows though.

Two problems with what you're doing: 1) syslogd doesn't allow others to modify the syslog -- if you try, it will stop logging to it. You'll have stop the daemon, do whatever changes to the log, thn start the daemon again. But you will lose important messages that come during that time. Bad idea. 2) the way you do that through crond, it will start two separate instances of sed at the same time, and you'll have race condition, as each of the two stream editors will write to their own copies of the syslog and than try rename it back to syslog. Bad idea. Instead of going through crond, you may as well have a single script with one infinite loop and a 5 min sleep inside it. But still a bad idea. In general, meddling with the syslog is a BAD idea! Instead, look into the config files of whatever is writing those lines (avahi?) and adjust the log level there. That can't happen. syslogd is NOT writing to the flash drive. (unless you've modified its config to do so on purpose). In v.5, the syslog is in a size-limited tmpfs in RAM. So nothing bad will happen as a result of its growing. It will just stop growing once it reaches a certain size (128MB? grep /var/log /proc/mounts). That may take a very long time though.

A few things come to mind. Try this: sysctl -w net.core.rmem_default=163840 sysctl -w net.core.wmem_default=163840 sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 sysctl -w net.ipv4.tcp_rmem='4096 131072 16777216' sysctl -w net.ipv4.tcp_wmem='4096 131072 16777216' sysctl -w net.ipv4.tcp_window_scaling=1 sysctl -w net.ipv4.tcp_mtu_probing=1 ifconfig eth0 txqueuelen 3000 ifconfig eth1 txqueuelen 3000 sysctl -w net.core.netdev_max_backlog=3000 sysctl -w net.ipv4.tcp_max_syn_backlog=4096 sysctl -w vm.min_free_kbytes=65536 read xx MEM xx <<<`grep 'MemTotal:' /proc/meminfo` if [ "$MEM" -gt 2048000 ] ;then sysctl -w vm.min_free_kbytes=131072 ;fi With the above tweaks applied, can you still reproduce the "network name is no longer available" problem?

Right. That's not the subject of this thread though. We were trying to trouble shoot a particular problem.

Do you mean like abandoning unRAID? Or, do you mean making all that work in unRAID? Either way, good luck with that. Let us know how it goes.

You don't need a full Slackware install for that, just the kernel. You can easily test that theory like this: - Grab the latest prebuilt kernel from the Slackware-64 repo, and the corresponding kernel modules; - Repack unRAID's bzroot to insert the new kernel modules folder in it; - Add an entry in syslinux.cfg that uses the new kernel and the repackaged bzroot; - Edit the go script to NOT start emhttp; - Reboot; - Start Samba manually; - Test to see if you still have that problem or not. If that turns out that this makes your problem go away, then you can easily build yourself a new kernel with the unRAID's driver as module for it. Then you can happily use all the ram you can fit in that server, no need to limit anything.

limiting to 4GB did fix the error for me on the following servers: - Supermicro X8SIL-F + Xeon X3440 - Supermicro X7DBE + 2x Xeon L5420 - Supermicro H8DAE + 2x Opteron 275 The problem was reproduceable not only with unRAID, but with other 32-bit distros with PAE. BTW, an alternative way to make the problem go away was booting a 64-bit kernel. (with the same 32-bit userspace) If the mem option doesn't fix it for you, then you must have other problems on top of that. Your nForce NIC is a prime suspect, as mentioned in earlier post.

Yes. You can try it and see for yourself how it allocates the memory. That fork has two paths: #1: mem is less than 4gb. (Disables all PAE crap.) #2: mem is not less than 4gb. i.e., it is 4gb-or-more. (Uses signifficant chunks of precious lowmem just to keep track of highmem.) So your 4gb is not a special case -- it falls under #2, just like 8gb or 16gb etc..