From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhcdX-0008MQ-Hr for qemu-devel@nongnu.org; Wed, 29 May 2013 05:25:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhcdO-0000fq-I8 for qemu-devel@nongnu.org; Wed, 29 May 2013 05:25:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhcdO-0000fK-AR for qemu-devel@nongnu.org; Wed, 29 May 2013 05:25:30 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4T9PRvY021958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 May 2013 05:25:29 -0400 Received: from localhost (vpn1-7-221.ams2.redhat.com [10.36.7.221]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r4T9PQ0x020713 for ; Wed, 29 May 2013 05:25:26 -0400 Date: Wed, 29 May 2013 10:25:23 +0100 From: "Richard W.M. Jones" Message-ID: <20130529092523.GL4515@redhat.com> References: <1369373827-9152-1-git-send-email-famz@redhat.com> <20130528103520.GB5105@redhat.com> <20130528110155.GC5105@redhat.com> <20130528111401.GA11749@localhost.nay.redhat.com> <20130528112539.GH4515@redhat.com> <20130528113215.GD5105@redhat.com> <20130529010725.GA3181@localhost.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130529010725.GA3181@localhost.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, May 29, 2013 at 09:07:25AM +0800, Fam Zheng wrote: > On Tue, 05/28 12:32, Richard W.M. Jones wrote: > > > > This fixes the obvious bug. > > Thanks for figuring out this. Mainline had this 5s timeout so I kept it, > but you don't experience this bug, right? Since master doesn't setup a > timer to get curl notified about the timing, the option is just not > effective. Indeed, qemu master has: curl_easy_setopt(state->curl, CURLOPT_TIMEOUT, 5); but I don't encounter the bug when using master, and I'm pretty certain about that because I've tested it a lot. It could be that qemu master manages to recover from / restart these incomplete reads, and doesn't deliver EIO up to the guest. > > I wonder if it should be even larger? One use for curl is to install > > guests using ISOs from websites without having to download the ISO, > > and I imagine that even a 30 second timeout could be conservative for > > that task. > > > > Long latency network is common in practice, as well as low bandwidth, > the meaning of the timeout is to complete the request, in extreme cases > if it is a 1Kbps link, downloading 256k takes minutes. Anyway, I think > making it larger won't hurt. I tried playing around with timeouts yesterday. Inside the guest there is a SCSI timeout (30 seconds default, see [1]). This has to be made larger if we make the qemu timeout larger than 30 seconds. With upstream qemu I can increase this timeout to 180 seconds and so read ISOs from slow public websites. (Try changing the test script so the 'disk' variable points to an ISO such as [2]). With the v6 patch, adjusting the SCSI timeout in the guest doesn't have any effect -- the SCSI disk "aborts" after ~40 seconds whatever I do. Rich. [1] http://kb.vmware.com/kb/1009465 [2] http://mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/releases/18/Live/x86_64/ -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top