Message-ID: <4CAE3BF1.2040300@idesis.de>
Date:	Thu, 07 Oct 2010 23:30:25 +0200
From:	Dimitrij Goldstein <Dimitrij.Goldstein@...sis.de>
To:	linux-kernel@...r.kernel.org
CC:	Alexander Constantin <constantin@...nal7.de>,
	René Lanfermann <rl@...sis.de>,
	Herr Klaus Peter Küßner 
	<kpk@...sis.de>
Subject: PROBLEM: copy process with NFS participation makes it impossible
 to start external process from parallel thread

  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@...lder10.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@...sis.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
––––––––––––––––––––––––––––––

Download attachment "iotest2.zip" of type "application/x-zip-compressed" (9156 bytes)

View attachment "cpuinfo" of type "text/plain" (1086 bytes)

View attachment "iomem" of type "text/plain" (3136 bytes)

View attachment "ioports" of type "text/plain" (1271 bytes)

View attachment "modules" of type "text/plain" (4465 bytes)

View attachment "pciinfo" of type "text/plain" (63510 bytes)

View attachment "scsi" of type "text/plain" (176 bytes)

View attachment "ver_linux.log" of type "text/plain" (1427 bytes)

Powered by blists - more mailing lists