freebsd stable - May 2015 - zfs, cam sticking on failed disk

On 07/05/2015 14:29, Ronald Klop wrote:
> On Thu, 07 May 2015 15:23:58 +0200, Steven Hartland 
> <killing at multiplay.co.uk> wrote:
>
>>
>>
>> On 07/05/2015 14:10, Slawa Olhovchenkov wrote:
>>> On Thu, May 07, 2015 at 02:05:11PM +0100, Steven Hartland wrote:
>>>
>>>>
>>>> On 07/05/2015 13:51, Slawa Olhovchenkov wrote:
>>>>> On Thu, May 07, 2015 at 01:46:40PM +0100, Steven Hartland
wrote:
>>>>>
>>>>>>>> Yes in theory new requests should go to the
other vdev, but
>>>>>>>> there could
>>>>>>>> be some dependency issues preventing that such
as a syncing TXG.
>>>>>>> Currenly this pool must not have write activity
(from application).
>>>>>>> What about go to the other (mirror) device in the
same vdev?
>>>>>>> Same dependency?
>>>>>> Yes, if there's an outstanding TXG, then I believe
all IO will
>>>>>> stall.
>>>>> Where this TXG released? When all devices in all vdevs
report
>>>>> 'completed'? When at the least one device in all
vdevs report
>>>>> 'completed'? When at the least one device in at
least one vdev report
>>>>> 'completed'?
>>>> When all devices have report completed or failed.
>>> Thanks for explained.
>>>
>>>> Hence if you pull the disk things should continue as normal,
with the
>>>> failed device being marked as such.
>>> I am have trouble to phisical access.
>>> May be someone can be suggest software method to forced detach
device
>>> from system.
>> In 11 that should be possible with devctl, but under 10 I'm not
aware
>> of anything that wouldn't involve some custom kernel level code
I'm
>> afraid.
>>
>
>
> Maybe I'm talking BS here, but does 'camcontrol eject' do
something on
> a disk?
I wouldn't have thought so, I would expect that to only have an effect 
on removal media such as CDROM drives, but no harm in trying ;-)

     Regards
     Steve

On 05/07/15 14:32, Steven Hartland wrote:
> 
> 
> On 07/05/2015 14:29, Ronald Klop wrote:
>> On Thu, 07 May 2015 15:23:58 +0200, Steven Hartland
>> <killing at multiplay.co.uk> wrote:
>>
>>>
>>>
>>> On 07/05/2015 14:10, Slawa Olhovchenkov wrote:
>>>> On Thu, May 07, 2015 at 02:05:11PM +0100, Steven Hartland
wrote:
>>>>
>>>>>
>>>>> On 07/05/2015 13:51, Slawa Olhovchenkov wrote:
>>>>>> On Thu, May 07, 2015 at 01:46:40PM +0100, Steven
Hartland wrote:
>>>>>>
>>>>>>>>> Yes in theory new requests should go to the
other vdev, but
>>>>>>>>> there could
>>>>>>>>> be some dependency issues preventing that
such as a syncing TXG.
>>>>>>>> Currenly this pool must not have write activity
(from application).
>>>>>>>> What about go to the other (mirror) device in
the same vdev?
>>>>>>>> Same dependency?
>>>>>>> Yes, if there's an outstanding TXG, then I
believe all IO will
>>>>>>> stall.
>>>>>> Where this TXG released? When all devices in all vdevs
report
>>>>>> 'completed'? When at the least one device in
all vdevs report
>>>>>> 'completed'? When at the least one device in at
least one vdev report
>>>>>> 'completed'?
>>>>> When all devices have report completed or failed.
>>>> Thanks for explained.
>>>>
>>>>> Hence if you pull the disk things should continue as
normal, with the
>>>>> failed device being marked as such.
>>>> I am have trouble to phisical access.
>>>> May be someone can be suggest software method to forced detach
device
>>>> from system.
>>> In 11 that should be possible with devctl, but under 10 I'm not
aware
>>> of anything that wouldn't involve some custom kernel level code
I'm
>>> afraid.
>>>
>>
>>
>> Maybe I'm talking BS here, but does 'camcontrol eject' do
something on
>> a disk?
> I wouldn't have thought so, I would expect that to only have an effect
> on removal media such as CDROM drives, but no harm in trying ;-)
zpool offline -t zroot da19

	Cheers,

	Matthew



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150507/cc165190/attachment.sig>