Hello everybody. [1.] One line summary of the problem: Copy process with NFS participation makes it impossible to start external process from parallel thread. [2.] Full description of the problem/report: Some Java program copies huge files and in another thread will start some external processes. If in the copy process participate as source or destination an NFS share, it makes impossible or with a big delay (from one second up to many seconds) external process to start. The problem is to observe on different linux distributions such as SuSE or CentOS and different JVMs 1.4.0, 1.6.0 etc. Logically represented that such problem can't be the Java problem because JVM doesn't know about source or destination file system. But to be sure we have implemented some small C program which makes the same. In the main thread it writes some file with size of 10GB onto the file system and in parallel thread it tries to start '/usr/bin/test' in loop with one second delay. During the program progress the processor isn't fully loaded. The behavior is the same. External program is possible to run once in 26 seconds after the writing the file. You can see results in iotest2.zip/result.log. Such problem can't be observed, for example, on Mac OS X or FreeBSD. [3.] Keywords (i.e., modules, networking, kernel): NFS, lock, rpciod, fork, exec. [4.] Kernel version (from /proc/version): Linux version 2.6.18-194.17.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Wed Sep 29 12:50:31 EDT 2010 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) Not applicable. [6.] A small shell script or example program which triggers the problem (if possible) Example program is attached in iotest2.zip. [7.] Environment [7.1.] It's a standard installation of the CentOS 5.5 with all current updates. Attached in ver_linux.log. [7.2.] Processor information (from /proc/cpuinfo): Attached in cpuinfo. [7.3.] Module information (from /proc/modules): Attached in modules. [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) Attached in ioports and iomem. [7.5.] PCI information ('lspci -vvv' as root) Attached in pciinfo. [7.6.] SCSI information (from /proc/scsi/scsi) Attached in scsi. [7.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant): None. [X.] Other notes, patches, fixes, workarounds: Workaround: Write file with small pieces and with small sleeps between writes. But naturally with performance losses. Many thanks in advance, –––––––––––––––––––––––––––––– Dipl.-Inform. (FH/UA) Dimitrij Goldstein Software Architect T +49 (0700) 433747 01 F +49 (0700) 433747 99 M +49 (0163) 433747 6 E dimitrij.goldstein@idesis.de idesis GmbH Rellinghauser Straße 334F D-45136 Essen www.idesis.de Geschäftsführer Mathias Koch Klaus Peter Küßner Michael Nitze Sitz und Amtsgericht: Essen HRB 18909 USt-IdNr. DE814609492 ––––––––––––––––––––––––––––––