From owner-freebsd-xen@freebsd.org Thu Sep 21 11:33:40 2017 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92DB5E25E84 for ; Thu, 21 Sep 2017 11:33:40 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from smtp.krpservers.com (smtp.krpservers.com [62.13.128.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.krpservers.com", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A5537562E for ; Thu, 21 Sep 2017 11:33:39 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from [10.12.30.106] (host86-162-208-244.range86-162.btcentralplus.com [86.162.208.244]) (authenticated bits=0) by smtp.krpservers.com (8.15.2/8.15.2) with ESMTPSA id v8LBXTnT004730 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Sep 2017 12:33:30 +0100 (BST) (envelope-from kpielorz_lst@tdx.co.uk) Date: Thu, 21 Sep 2017 12:33:24 +0100 From: Karl Pielorz To: "Rodney W. Grimes" cc: freebsd-xen@freebsd.org Subject: Re: Storage 'failover' largely kills FreeBSD 10.x under XenServer? Message-ID: <1913BD3E6623F2384770C39E@[10.12.30.106]> In-Reply-To: <201709201815.v8KIF7Gi089958@pdx.rh.CN85.dnsmgr.net> References: <201709201815.v8KIF7Gi089958@pdx.rh.CN85.dnsmgr.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 11:33:40 -0000 --On 20 September 2017 11:15 -0700 "Rodney W. Grimes" wrote: > As you found one of these let me point out the pair of them: > kern.cam.ada.default_timeout: 30 > kern.cam.ada.retry_count: 4 Adjusting these doesn't seem to make any difference at all. All the VM's (the control one, running defaults) - and the 3 others (one running longer timeouts, one running more retries - and one running both longer timeouts and retries) - all start throwing I/O errors on the console at the same time (e.g. regardless if the timeout is set to default 30 seconds, or extended out to 120) - I/O errors pop up at the same time. It looks like they're either ignored, or 'not applicable' for this scenario. Of particular concern is - if I adjust the 'timeout' value from 30 to 100 seconds, and 'time' how long the first I/O error takes to appear on the console, it's still ~30 seconds. I'm going to re-setup the test VM's - with a 'stable' boot disk (that won't go away during the switch) to give me something to log to - I should be able to work out the timings involved then, to see if the first I/O error really does surface after 30 seconds, or not. If the timeout is set to, say 100 seconds - I shouldn't see any console errors until then, should I? - unless some other part of the storage stack is still timing out first at 30 seconds? -Karl