From owner-freebsd-stable@FreeBSD.ORG Thu Nov 18 02:16:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 184801065777 for ; Thu, 18 Nov 2010 02:16:08 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0658E8FC18 for ; Thu, 18 Nov 2010 02:16:07 +0000 (UTC) Received: by qyk7 with SMTP id 7so784566qyk.13 for ; Wed, 17 Nov 2010 18:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HSsahYp47sJ/d5n/OdxaQeKmkbZ35euSUXXPetJ3bjA=; b=dlGlpFW4p/bRRhIGCioKnbBCkNiEAMkppWLcqU+u85nEAdbXbyk0i4zSPoIsL8K4PI jKo/hR8Sy+ZWestXEFlVHpjEDrto5rH5IWfsV7AhqAyg4huybJrLmyNnQIttKGRqtln2 TLvx/3MQydA9fAINAw8ctbM95RDUTQ0+lXIZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q9pBFeM9/71tQpJnGYUPMAlpqu5UpI80C0HKbVhDjpDa9x6xz/U8o2jPjIkC6/msw4 uxz1/MVtrwy+kLJ9MOZRjYEjjC2WRbfV9ufDNwDMNhwNs6ivuTZXd59kYu0IflqRnQdF 4TFpuJ8xqPgpMSNZOcrwMaDnMFKxjF1J80D5o= MIME-Version: 1.0 Received: by 10.229.238.148 with SMTP id ks20mr8137427qcb.262.1290046567410; Wed, 17 Nov 2010 18:16:07 -0800 (PST) Received: by 10.229.85.149 with HTTP; Wed, 17 Nov 2010 18:16:07 -0800 (PST) In-Reply-To: <4CE36054.6010503@DataIX.net> References: <4CD6243B.90707@DataIX.net> <4CE36054.6010503@DataIX.net> Date: Wed, 17 Nov 2010 18:16:07 -0800 Message-ID: From: Rumen Telbizov To: jhell Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Artem Belevich Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 02:16:11 -0000 Hi jhell, everyone, Thanks for your feedback and support everyone. Indeed after successfully disabling /dev/gptid/* zfs managed to find all the gpt/ labels without a problem and the array looked exactly the way it did in the very beginning. So at that point I could say that I was able to fully recover the array without data loss to exactly the state it was in the beginning of its creation. Not without adventure though ;) Ironically due to some other reasons just after I fully recovered it I had to destroy it and rebuild from scratch with raidz2 vdevs (of 8 disks) rather than raidz1s (of 4 disks) ;) Basically I need better redundancy so that I can handle double disk failure in a vdev. Seems like the chance of a second disk failing while rebuilding the zpool for like 15 hours on those 2TB disks is quite significant. I wonder if this conversion will reduce the IOPs of the pool in half ... Anyway, thank you once again. Highly appreciated. I hope this is a helpful piece of discussion for other people having similar problems. Cheers, Rumen Telbizov On Tue, Nov 16, 2010 at 8:55 PM, jhell wrote: > On 11/16/2010 16:15, Rumen Telbizov wrote: > > It seems like *kern.geom.label.gptid.enable: 0 *does not work anymore? I > am > > pretty sure I was able to hide all the /dev/gptid/* entries with this > > sysctl variable before but now it doesn't quite work for me. > > I could be wrong but I believe that is more of a loader tuneable than a > sysctl that should be modified at run-time. Rebooting with this set to 0 > will disable showing the /dev/gptid directory. > > This makes me wonder if those sysctl's should be marked read-only at > run-time. Though you could even rm -rf /dev/gptid ;) > > -- > > jhell,v > -- Rumen Telbizov http://telbizov.com