zfs, cam sticking on failed disk

Slawa Olhovchenkov slw at zxy.spb.ru
Thu May 7 12:05:16 UTC 2015


On Thu, May 07, 2015 at 01:00:40PM +0100, Steven Hartland wrote:

> 
> 
> On 07/05/2015 11:46, Slawa Olhovchenkov wrote:
> > On Thu, May 07, 2015 at 11:38:46AM +0100, Steven Hartland wrote:
> >
> >>>>> How I can cancel this 24 requst?
> >>>>> Why this requests don't timeout (3 hours already)?
> >>>>> How I can forced detach this disk? (I am lready try `camcontrol reset`, `camconrol rescan`).
> >>>>> Why ZFS (or geom) don't timeout on request and don't rerouted to da18?
> >>>>>
> >>>> If they are in mirrors, in theory you can just pull the disk, isci will
> >>>> report to cam and cam will report to ZFS which should all recover.
> >>> Yes, zmirror with da18.
> >>> I am surprise that ZFS don't use da18. All zpool fully stuck.
> >> A single low level request can only be handled by one device, if that
> >> device returns an error then ZFS will use the other device, but not until.
> > Why next requests don't routed to da18?
> > Current request stuck on da19 (unlikely, but understund), but why
> > stuck all pool?
> 
> Its still waiting for the request from the failed device to complete. As 
> far as ZFS currently knows there is nothing wrong with the device as its 
> had no failures.

Can you explain some more?
One requst waiting, understand.
I am do next request. Some information need from vdev with failed
disk. Failed disk more busy (queue long), why don't routed to mirror
disk? Or, for metadata, to less busy vdev?

> You didn't say which FreeBSD version you where running?

10-STABLE, r281264.


More information about the freebsd-stable mailing list