> > The system became non-responsible after two drives was lost, and > > replaced with spares, in that VDEV. That bug has been filed and > > acknowleged. Take a RAIDz2 with two spares and remove a drive from > > the pool, let it resilver to a spare, remove another, wait until it > > resilvers again, and remove the third. The system will become rather > > dead - even the rpool will be unavailable, even if both the data > > pool and the rpool are bothe theoretically healthy > > Can't say I've ever run into that situation. I'd suggest looking into > the pool failmode setting but that still wouldn't make a lot of sense. > Any idea why you are getting so many failures?
CC:ing this to the appropriate lists As a first, the default is to let go of failed devices. I haven't tweaked that part, nor any part of the pool. If a drive failes, it should be replaced by a spare, and when a drive is replaced by a new one, the old "ghost" should disappear. Neither of this happens at times. It seems sometimes the zpool "forgets" a dead drive and let ihang. This may trigger the bug which turns a pool and indeed the system unusable (if two drives in a raidz2 are lost, but resilvererd, losing the third will hang the system). The remedy seemed to be to zpool detach the drives. Still, the bug(s) exist(s) to allow a system to be rendered unusable just with a few drives lost, long before the pool is lost. Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 r...@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss