Date: Thu, 21 Sep 2017 13:40:07 +0100 From: Karl Pielorz <kpielorz_lst@tdx.co.uk> To: rainer@ultra-secure.de Cc: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net>, 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7D39973713EC8FB944D4BA4F>