> --On 21 September 2017 14:04 +0200 rai...@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'.
Ok, need to sort that out for certain to get much further.
What are you running for Dom0?
Did you do the sysctl's in Dom0 or in the guest?
To be effective I would think they would need to be run
in the guest, but if DOM0 is timing out and returning
an I/O error then they well have to be adjusted there first.
> > If they don't show-up there, why should any cam timeouts apply?
> It appears they don't :) (at least, so far).
Are these timeouts coming from Dom0 or from a VM in a DomU?
> > 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.
Windows has horrible long timeouts and large retry counts, and worse
they dont warn the user that it is having issues other than event logs
and things usually go to the state of drive catastrophic failure before
the user ever sees an error.
> 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.
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Rod Grimes rgri...@freebsd.org
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"