From owner-freebsd-xen@freebsd.org Thu Sep 21 12:40:16 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 4FC21E0187A; Thu, 21 Sep 2017 12:40:16 +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 EA0A37C30D; Thu, 21 Sep 2017 12:40:15 +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 v8LCeCtF009249 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Sep 2017 13:40:13 +0100 (BST) (envelope-from kpielorz_lst@tdx.co.uk) Date: Thu, 21 Sep 2017 13:40:07 +0100 From: Karl Pielorz To: rainer@ultra-secure.de cc: "Rodney W. Grimes" , freebsd-xen@freebsd.org, owner-freebsd-xen@freebsd.org Subject: Re: Storage 'failover' largely kills FreeBSD 10.x under XenServer? Message-ID: <7D39973713EC8FB944D4BA4F@[10.12.30.106]> In-Reply-To: <5afd1ad53171583603bb8518dfbdd51b@ultra-secure.de> References: <201709201815.v8KIF7Gi089958@pdx.rh.CN85.dnsmgr.net> <1913BD3E6623F2384770C39E@[10.12.30.106]> <5afd1ad53171583603bb8518dfbdd51b@ultra-secure.de> 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 12:40:16 -0000 --On 21 September 2017 14:04 +0200 rainer@ultra-secure.de wrote: > I asked myself already if the disks from Xen(Server) are really CAM-disks. > > They certainly don't show up with camcontrol devlist. So they don't. I presumed they were cam, as they're presented as 'ada0'. > If they don't show-up there, why should any cam timeouts apply? It appears they don't :) (at least, so far). > BTW: storage-failures also kill various Linux hosts. > They usually turn their filesystem into read-only mode and then you've > got to reboot anyway. Yes, I know - it's a bit of an upheaval to cope with storage fail over - annoyingly the windows boxes (though they go 'comatose' while it's happening) all seem to survive. I could cope with a few VM's rebooting - but to see so many just fold and panic, adds a lot of "insult to injury" at fail over time :( [And I know, if I/O is unavailable you're going to be queuing up a whole 'world of pain' anyway for when it returns, such as listen queues, pending disk I/O, hung processes waiting for I/O etc. etc.) - but to have a fighting chance of unwinding it all when I/O recovers - would be good. -Karl