From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 04:00:02 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 653F31065670 for ; Sun, 7 Nov 2010 04:00:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 00BB38FC08 for ; Sun, 7 Nov 2010 04:00:01 +0000 (UTC) Received: by yxl31 with SMTP id 31so2963832yxl.13 for ; Sat, 06 Nov 2010 21:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=0EKTb5Ee2WPaTsWqpFQrfM7IFvwE3UYGUME/HQG2dJM=; b=lVmp4ZX3orUtR3oRr+e9icAYs9ofQ5xe5jZzfIZnjJiHfJqThZQat7r4yxktW9t+3E PBmv4dV3TwgmQblhveQkReEM/ez4EH7w1A4N3IaGOMe61ejrKPxgvIERufKalLMrF8e6 q85kYOjGFu3NWgATlTOhZleeCrhttX7ksL95Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ROpUAwNPd3axRSRp86MRfIxXsLfhHHWnKoBeZGP/kDhnY53mYXYuy5GhgaPZggUGkD LjArVMK6NqwvbF4UOhuBqWnw7HIaJTbQDID36iaMtIHOJFPBZZ1oBVwAlVbM6KJKnqf4 rYBoD3ZH/ZkLu7TGdr4LbHHf5rh62kkC0t/+4= Received: by 10.151.42.15 with SMTP id u15mr6166743ybj.222.1289102401094; Sat, 06 Nov 2010 21:00:01 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-136-243.dsl.klmzmi.sbcglobal.net [99.181.136.243]) by mx.google.com with ESMTPS id p1sm2466377ybn.17.2010.11.06.20.59.57 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 20:59:58 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CD6243B.90707@DataIX.net> Date: Sat, 06 Nov 2010 23:59:55 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Rumen Telbizov References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sun, 07 Nov 2010 04:00:02 -0000 On 10/31/2010 15:53, Rumen Telbizov wrote: > Hi Artem, everyone, > > Here's the latest update on my case. > I did upgrade the system to the latest stable: 8.1-STABLE FreeBSD 8.1-STABLE > #0: Sun Oct 31 11:44:06 PDT 2010 > After that I did zpool upgrade and zfs upgrade -r all the filesystems. > Currently I am running zpool 15 and zfs 4. > Everything went fine with the upgrade but unfortunately my problem still > persists. There's no difference in this aspect. > I still have mfid devices. I also tried chmod-ing as you suggested /dev/mfid > devices but zfs/zpool didn't seem to care and imported > the array regardless. > > So at this point since no one else seems to have any ideas and we seem to be > stuck I am almost ready to declare defeat on this one. > Although the pool is usable I couldn't bring it back to exactly the same > state as it was before the disk replacements took place. > Disappointing indeed, although not a complete show stopper. > > I still think that if there's a way to edit the cache file and change the > devices that might do the trick. > > Thanks for all the help, > Rumen Telbizov > > > On Fri, Oct 29, 2010 at 5:01 PM, Artem Belevich wrote: > >> On Fri, Oct 29, 2010 at 4:42 PM, Rumen Telbizov >> wrote: >>> FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 >>> That's when I csuped and rebuilt world/kernel. >> >> There were a lot of ZFS-related MFCs since then. I'd suggest updating >> to the most recent -stable and try again. >> >> I've got another idea that may or may not work. Assuming that GPT >> labels disappear because zpool opens one of the /dev/mfid* devices, >> you can try to do "chmod a-rw /dev/mfid*" on them and then try >> importing the pool again. >> >> --Artem >> > > > The problem seems to be that its just finding the actual disk before it finds the GPT labels. You should be able to export the pool and then re-import the pool after hiding the disks that it is finding via /etc/devfs.rules file. Try adding something like (WARNING: This will hide all devices mfi) adjust accordingly: add path 'mfi*' hide To your devfs ruleset before re-importing the pool and that should make ZFS go wondering around /dev enough to find the appropriate GPT label for the disk it is trying to locate. It would seem to me that using '-d' in this case would not be effective as ZFS would be looking for 'gpt/LABEL' within /dev/gpt/ if memory serves correctly, and obviously path /dev/gpt/gpt/ would not exist. Also even if it did find the correct gpt label then it would be assuming its at a /dev path and not /dev/gpt/* and would fall back to finding the mfi devices after the next boot again. -- jhell,v