Date: Sun, 3 Oct 2010 11:03:38 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Steve Polyack <korvus@comcast.net> Cc: mav@FreeBSD.org, freebsd-stable <freebsd-stable@freebsd.org>, Dan Langille <dan@langille.org>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: out of HDD space - zfs degraded Message-ID: <20101003110338.00004197@unknown> In-Reply-To: <4CA7E98E.3040701@comcast.net> References: <4CA73702.5080203@langille.org> <20101002141921.GC70283@icarus.home.lan> <4CA7AD95.9040703@langille.org> <20101002223626.GB78136@icarus.home.lan> <4CA7BEE4.9050201@langille.org> <20101002235024.GA80643@icarus.home.lan> <4CA7E4AE.4060607@langille.org> <4CA7E98E.3040701@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 02 Oct 2010 22:25:18 -0400 Steve Polyack <korvus@comcast.net> wrote: > I thin its worth it to think about TLER (or the absence of it) here - > http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery . Your > consumer / SATA Hitachi drives likely do not put a limit on the time > the drive may block on a command while handling inernal errors. If > we consider that gpt/gisk06-live encountered some kind of error and > had to relocate a significant number of blocks or perform some other > error recovery, then it very well may have timed out long enough for > siis(4) to drop the device. I have no idea what the timeouts are set > to in the siis(4) driver, nor does anything in your SMART report > stick out to me (though I'm certainly no expert with SMART data, and > my understanding is that many drive manufacturers report the various > parameters in different ways). IIRC mav@ (CCed) made a commit regarding this to -current in the not so distant past. I do not know about the MFC status of this, or if it may have helped or not in this situation. Bye, Alexander.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101003110338.00004197>