Date: Wed, 26 Jan 2011 10:20:20 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r217828 - projects/graid/head/sys/geom/raid Message-ID: <alpine.BSF.2.00.1101261018370.44308@fledge.watson.org> In-Reply-To: <4D3FED31.8040304@FreeBSD.org> References: <201101251534.p0PFY7cF039182@svn.freebsd.org> <201101251117.49069.jhb@freebsd.org> <alpine.BSF.2.00.1101260923140.44308@fledge.watson.org> <4D3FED31.8040304@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Jan 2011, Alexander Motin wrote: > That's all true. Those who want maximum robustness should use dedicated > drive on the most trivial dedicated controller to make dumping reliable. If > we are going above that - there are always some compromises. This seems to be the best conclusion in the NIC space certainly -- for network debugging and crashdumps, a dedicated NIC involves far fewer compromises. However, the traditional route of resetting $controller when you realise you're past the point of no return, and then doing polled I/O to the freshly initialised device, should be pretty reliable under most circumstances. > What's about dumping to GEOM, I think that with r217827 change (in > projects/graid/head) it should be possible to implement robust dumping to > gmirror and gstripe without doing any allocations and GEOM interaction. With > some efforts it could also be done to graid by writing specialized > minimalistic dumping routines for every transformation module (at least it > seems trivial for RAID0/RAID1). Sounds good. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1101261018370.44308>