Date: Thu, 07 May 2015 15:28:30 +0100 From: Matthew Seaman <matthew@freebsd.org> To: freebsd-stable@freebsd.org Subject: Re: zfs, cam sticking on failed disk Message-ID: <554B768E.8090705@freebsd.org> In-Reply-To: <554B696F.6020902@multiplay.co.uk> References: <20150507095048.GC1394@zxy.spb.ru> <554B40B6.6060902@multiplay.co.uk> <20150507104655.GT62239@zxy.spb.ru> <554B53E8.4000508@multiplay.co.uk> <20150507120508.GX62239@zxy.spb.ru> <554B5BF9.8020709@multiplay.co.uk> <20150507124416.GD1394@zxy.spb.ru> <554B5EB0.1080208@multiplay.co.uk> <20150507125129.GY62239@zxy.spb.ru> <554B6307.9020309@multiplay.co.uk> <20150507131007.GZ62239@zxy.spb.ru> <554B676E.8020500@multiplay.co.uk> <op.xx9o261skndu52@ronaldradial.radialsg.local> <554B696F.6020902@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Od1rfIBs561nhQrNclap7aGGflXABCcQd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/07/15 14:32, Steven Hartland wrote: >=20 >=20 > On 07/05/2015 14:29, Ronald Klop wrote: >> On Thu, 07 May 2015 15:23:58 +0200, Steven Hartland >> <killing@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= =2E >>>>>>>> Currenly this pool must not have write activity (from applicatio= n). >>>>>>>> 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 rep= ort >>>>>> 'completed'? >>>>> When all devices have report completed or failed. >>>> Thanks for explained. >>>> >>>>> Hence if you pull the disk things should continue as normal, with t= he >>>>> failed device being marked as such. >>>> I am have trouble to phisical access. >>>> May be someone can be suggest software method to forced detach devic= e >>>> 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 --Od1rfIBs561nhQrNclap7aGGflXABCcQd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVS3aOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnshYP/AioJFd200EuPkS4jv2tz7mg eL9aPcevnhGsjHdow9DWVNZTJyjRUVH9mKzyJcZHZsnD8xQptaK+pqRuaOEUeUtv l5PQ1BnpeFGuv8ogy19G5bSewiB+apanUZvcfvJJXObHxpDLflA6Xh0lx3xgHmSD ghFtzz6sdK3RJbHucKcF+ToVN7OeK5VGTUiNuXJriwOLME/wRzlzWXsGdB7xBBNz dTgx88sN/1YxUwvtG9PCEeYd6u4cQYSEKSw/9PR1jk/ZxKKmDYi82bi/n+kqGxZz HnYzJwQxeRl2aJuNlxIRGpO5vRPN9iZc89hKEVQmPnPz++sk/GwN09PYjAqSedwl wBufFlLEYQhtTwxO5Sd7BL2Vta3Dx1R7sP6rZS+55Dom/p0N+VuXF9hVWVkYlM0i 5wiVjw8MIzOVu5aM7nX7IoKgnrWhtw2NLbrxP756XVO7KMKPjpC8U4XIomFuShYv 1eKJaul+K/Jo0p0ISR/aV5qrzhWnQ+A4+X2+EeMLB0IdIXICxuxIdmoWdzKM16uj JLA+M3rdv5Nom7Kyyy3c575EyAvZFFHQDl9CnYWUx5Bi9msTM/tJOwmkE+7Ya9nM XuO0nd6QvForLuydD8lbiTpsbvLZQYvFIbDPhHL06+CC4X0mdxnADDW6yheRFAdN LRbiYILM//Gjtv7zW8o9 =JXkT -----END PGP SIGNATURE----- --Od1rfIBs561nhQrNclap7aGGflXABCcQd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?554B768E.8090705>