From owner-freebsd-xen@freebsd.org Thu Sep 21 12:05:33 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 5B55FE27C58; Thu, 21 Sep 2017 12:05:33 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id 911AB76A1A; Thu, 21 Sep 2017 12:05:31 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Thu, 21 Sep 2017 14:04:19 +0200 Authentication-Results: connect.ultra-secure.de; auth=pass (login); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 127.0.0.10 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=127.0.0.10; helo=connect.ultra-secure.de; envelope-from= Received: from connect.ultra-secure.de (webmail [127.0.0.10]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id 337C7DD2-F54B-40D6-AF4C-17998A528C17.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO); Thu, 21 Sep 2017 14:04:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 21 Sep 2017 14:04:08 +0200 From: rainer@ultra-secure.de To: Karl Pielorz Cc: "Rodney W. Grimes" , freebsd-xen@freebsd.org, owner-freebsd-xen@freebsd.org Subject: Re: Storage 'failover' largely kills FreeBSD 10.x under XenServer? In-Reply-To: <1913BD3E6623F2384770C39E@[10.12.30.106]> References: <201709201815.v8KIF7Gi089958@pdx.rh.CN85.dnsmgr.net> <1913BD3E6623F2384770C39E@[10.12.30.106]> Message-ID: <5afd1ad53171583603bb8518dfbdd51b@ultra-secure.de> X-Sender: rainer@ultra-secure.de User-Agent: Roundcube Webmail/1.2.0 X-Haraka-GeoIP: --, , NaNkm X-Haraka-GeoIP-Received: X-Haraka-p0f: os="undefined undefined" link_type="undefined" distance=undefined total_conn=undefined shared_ip=Y X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 266, bad: 0, connections: 266, history: 266, pass:all_good, relaying 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:05:33 -0000 Am 2017-09-21 13:33, schrieb Karl Pielorz: > --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. I asked myself already if the disks from Xen(Server) are really CAM-disks. They certainly don't show up with camcontrol devlist. If they don't show-up there, why should any cam timeouts apply? 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.