The CVS exclude option of rsync can be harmful in some cases.
For example I use rsync to keep my/this website updated. At some point I noticed some strange behavior after the update of several of the WordPress plugins I use. After a bit of investigation I noticed that one plugin (Broken Link Checker) has a directory which is named “core”. This is one of the filenames which are in the exclude list of the CVS exclude feature of rsync. Normally it should only prevent the transfer of core-files, but as rsync does not have a look if this is a file or a directory (it is not supposed to do this), it also prevents the transmission of the directory.
After modifying the rsync options to manually exclude the CVS patterns except for “core”, the site worked correctly again.
It seems this is one of those cases where different development/management cultures show some little incompatibilities.
Regarding our last problems with NW:
- OK: the “restart NW-server directly after deleting a client with index entries”-crash is fixed
- Mostly OK: shutting down a storage node does not crash the NW-server anymore… most of the time (sometimes there is some strange behavior in this regard, we do not have enough evidence, but there may be still some sleeping dragons)
- ?: we did not yet check the disaster recover part
- NOK: the post-cmd is still run one minute after the pre-cmd in some cases, maybe this is related to a session/save-set which is not yet started but the pre-cmd is already run, if this is the case, this could maybe also affect the case where there is more than one minute of delay between the end of one session/save-set on a machine and the start of another session/save-set on the same machine (the support is investigating)
- NOK: some Oracle-RMAN backups (custom save command, perl script) show a running session in the NW-monitoring and some do not, after the backup mminfo sometimes lists the group of a RMAN-save-set and sometimes not (for the same client), under investigation by the support
So, for us 188.8.131.52 is still a beta version.
Today I committed two patches which fix the last two panics we know about in the 2.6.16 emulation. Now we need testers. Here’s the text of the mail I did send to current@ a few moments ago:
today I committed the last fixes for the showstopper problems (panics) in the linux 2.6.16 emulation. I intend to switch the default version to 2.6.16 on i386 “soon” (see below), so please help testing it.
More recent linux distributions (e.g. FC5) require a 2.6 kernel and don’t work with 2.4.2 anymore. And because FC4 is “abandon-ware” (no security fixes from fedoralegacy anymore), getting 2.6.16 emulation up an running is very important.
If you use a linux program, please add compat.linux.osrelease=2.6.16 to /etc/sysctl.conf (my desktop is running with 2.6.16 emulation since some days already). After the next boot (or after running “sysctl compat.linux.osrelease=2.6.16”, please make sure no linux program is running already) any linux program will start with a linux kernel version of 2.6.16 instead of 2.4.2. The default linux base port (FC4) will then use different code paths (e.g. within glibc). In case you want to switch back to the 2.4.2 emulation without a reboot, please make sure no linux program is running anymore.
So far we fixed all known/repeatable problems with acroread, realplayer, skype and linux firefox. If you encounter strange behavior with any linux program, please tell us (email@example.com) which program you used, how to repeat the problem, what the problem is, and if it only is visible with 2.6.16 or with 2.4.2 too. You should also watch out for messages in the dmesg (unimplemented system calls or other stuff, this is used to determine the priority of missing syscalls). Please also have a look at http://wiki.FreeBSD.org/linux-kernel, I intend to document the known problems there. If you find your problem there, please tell us about it if you are willing to test fixes.
We are specially interested in reports (good or bad) on SMP systems. Please beat the hell out of the linuxulator!
On amd64 systems we have not the same functionality as on i386, missing are futexes and TLS. In P4 we already have the futex part covered, but the TLS part is still missing (anyone with a clue about the kernel side of TLS on amd64 is welcome to give a hint or two to jkim@ and rdivacky@). So if you get a message about missing futexes or TLS on amd64: we know about it (testers for the futex stuff are welcome, but first you need to use a program which uses futexes and complains).
As long as we get problem reports with 2.6.16 I will not switch the default to 2.6.16. If we don’t get a report at all, I will switch the default on i386 to 2.6.16 in two weeks. If we get some problem reports, we will push back the switch a little bit depending on the severity of the problem.