From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-02.nifty.com (conssluserg-02.nifty.com [210.131.2.81]) by sourceware.org (Postfix) with ESMTPS id B8FBC3858415 for ; Tue, 7 Sep 2021 11:03:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B8FBC3858415 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from Express5800-S70 (z221123.dynamic.ppp.asahi-net.or.jp [110.4.221.123]) (authenticated) by conssluserg-02.nifty.com with ESMTP id 187B3FrL018395 for ; Tue, 7 Sep 2021 20:03:16 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 187B3FrL018395 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1631012596; bh=TB+WX8Hkc5kVrp+1tfKhxHle/Si2FcqTb4kYpNk2y1o=; h=Date:From:To:Subject:In-Reply-To:References:From; b=A4QTX/dhuP3WxhUF5C/ampQMhy9at9EDus9GfwcLxAoWX3OK1jViYkuseKRrw9+rD cIBkwxGZBHi3FeZJ/+cIbRHsyaCGm9QTqpSm0CTNlW6w85+B0VaYzjMjv9WeF63JnT keKfKzdwcmfq4pJSSjch/pNFbsd0QJNeCDP2Y6zFtUAkg7AhRIjKe/oRVDNSlnvlo2 IE3Bf+lzH/J3D2hGukLYh94Hr0jXtjtmRxO8QqHM76HEKzqyEIF41JwPJe21koH9Bk WzS2UkEih6s7hgtoJRv0nK3lcB1UwV6E+qdb1Bc7oZohogcL76qX/WsFZaoPwgFoi6 FGV2IMUQPwFkQ== X-Nifty-SrcIP: [110.4.221.123] Date: Tue, 7 Sep 2021 20:03:17 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-Id: <20210907200317.78d2b649d96024b4eb9eb928@nifty.ne.jp> In-Reply-To: References: <20210905224059.cfdc8f23d3eeaa1ea16ecf2e@nifty.ne.jp> <20210905225037.c625ee0bcd479181848763f8@nifty.ne.jp> <20210906050950.56b397be7c5eb3da848691e9@nifty.ne.jp> <20210906201643.2e84c0d3a7ac7c8878548408@nifty.ne.jp> <20210906221649.8001d3cb554011d02309b407@nifty.ne.jp> <20210907083929.71ae792a4375825295d0c251@nifty.ne.jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2021 11:03:45 -0000 On Tue, 7 Sep 2021 11:14:28 +0200 Corinna Vinschen wrote: > On Sep 7 08:39, Takashi Yano wrote: > > On Mon, 6 Sep 2021 18:08:54 +0200 > > Corinna Vinschen wrote: > > > On Sep 6 22:16, Takashi Yano wrote: > > > > Current git head seems to have some bug. With and without my patch, > > > > sftp get for large file causes error: > > > > > > > > [yano@Express5800-S70 ~]$ sftp 192.168.0.133 > > > > yano@192.168.0.133's password: > > > > Connected to 192.168.0.133. > > > > sftp> get test.dat > > > > Fetching /home/yano/test.dat to test.dat > > > > test.dat 13% 66MB 66.4MB/s 00:06 ETAReceived message too long 1728053256 > > > > Ensure the remote shell produces no output for non-interactive sessions. > > > > [yano@Express5800-S70 ~]$ sftp 192.168.0.133 > > > > yano@192.168.0.133's password: > > > > Connected to 192.168.0.133. > > > > sftp> get test.dat > > > > Fetching /home/yano/test.dat to test.dat > > > > test.dat 22% 111MB 110.6MB/s 00:03 ETAdo_download: parse: incomplete message > > > > [yano@Express5800-S70 ~]$ > > > > > > I bisected this down to commit 296bd3e78b52, but I'm at a loss in > > > terms of the cause of the problem, ATM. > > > > Thanks for bisecting this. > > > > I am not sure this is the correct thing, however, found the following > > patch solves the issue. > > Thanks for the patch! It's not correct as such, because it enables > SA_RESTART behaviour unconditionally, but it gave me the right hint. > > The underlying problem is that in case of a signal, the CancelIo call > was missing. The signal was processed, but the IO was still ongoing > and so data was read or written without the application's knowledge. > > Actually we can always call CancelIo. It doesn't break the information > in the IO_STATUS_BLOCK if the IO was already finished. It just sets > io.Status to STATUS_CANCELLED and io.Information to the number of bytes > processed if it really canceled the ongoing IO. > > I pushed a matching patch. I have confirmed that your patch solves the issue. Thanks! -- Takashi Yano