X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=1.8 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
From: "Brebner, Gavin" <gavin DOT brebner AT hp DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date: Thu, 14 May 2009 10:05:22 +0000
Subject: I/O errors seen on programs passing via cygwin under heavy stress
Message-ID: <B0E0B6C348D8AB4BAD6290DC0BDE99D44F6AE7D6D8@GVW1115EXC.americas.hpqcorp.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

=20
I am routinely having problems with programs compiled and running via cygwi=
n if they are=20
using network shares and the level of I/O stress is high.=20
=20
In a typical case, I have a single Windows Server 2003 node with a single s=
hare open to all,=20
and 3 Windows Server 2003 clients each running an up-to-date cygwin who hav=
e mounted the share
via a mount //<ip address>/<share> /test.=20

On each client I compile and set off the ping_pong locking test which does =
byte level locking -=20
so far so good. If on one of those clients I then set off a heavy load gene=
rator compiled and=20
running within the cygwin environment e.g. iozone, the ping_pong tests star=
t reporting=20
'permission denied' and 'write failed'. iozone itself will generally fail w=
ith a write error=20
as well.

I have similar issues when using a range of other tests, including when usi=
ng Samba on Linux=20
as the back end server. I have tested with different systems and different =
networks and seen=20
the same result. However, if the load generator is a Windows native applica=
tion, the=20
problem is not seen.

It looks to me as if the cygwin environment has problems if the I/O traffic=
 becomes "excessive".
Note, if the application tries a retry of a failed write after a short dela=
y, it will generally=20
succeed, reinforcing my suspicions.=20

Googling and looking at the mail archives didn't seem to throw up anything =
similar, however.
Is this a known issue ? Are there ways of tuning the cygwin I/O subsystem ?

Thanks,

	Gavin




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/