From owner-freebsd-fs@freebsd.org Wed Sep 28 23:00:44 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C186C00B04; Wed, 28 Sep 2016 23:00:44 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF1109AF; Wed, 28 Sep 2016 23:00:43 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yw0-x22f.google.com with SMTP id i129so38332206ywb.0; Wed, 28 Sep 2016 16:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=L7T7g2cAVwgC+B5SUypGa6RrR07NC6NKO5/LevFl+qI=; b=rlrxkaple15bMahKGCkqL076NNeLr9rEHrlcC8+gPrHgcBYqV65JjYqKV/xVMPJGGA fgV80PDWNWNAWd9wmfR3N0uscCe1bwKhOUmmspS4yHwu1+lOoaI6N4V/8feMU4Q5094v Mp6efs2aG9/wCp78RJWKuPo7o4/hUCM8Qzi02CLm8jCxref9DXfAC4vPeUyS93qypPgO m5xIYNIk5GcMcFZDSnE7Pa9U0Vc1xEmPW2s/TDJ41bCK8vU+D/obU/ecLgwsb3gL8h2/ nDJdaaLQ2O1LIXHQKnP6AbI/54eRflPuLunL7C/y5mSB1dFiyjRXzCw62Wrq+Z/DJ3zu 6idQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=L7T7g2cAVwgC+B5SUypGa6RrR07NC6NKO5/LevFl+qI=; b=iNKVetoP4krr957gFMBaP29igpVLB0TMp6WZXNtytln3RDYCRu31QFZeifAcyX2itj VZ30DWoW9EEFMMADNPIqxBx252ymt3hBCfsM/U1yDRFKtp9xneJZk8RqYaF/jF1B/ROT AtLoHT5ZCM3tsklGqpfCQYmjeN96OH+Q6iNrEum45nbVhqnzm0O77ZYK6FNB0Je5qOAC n/VeKYl+2gag1sPNgemGaHs3/6macmI+Uyk4mUuS4ZzQPdHpzpbYGJ2+GRF6ywGm9FeE zlPIJ8tvWQQbvJq5iRrDemEno4JvpslvZVuPeB9vNuVGrg5E/Esp4t85tvSkHY9yqkO8 NO+A== X-Gm-Message-State: AE9vXwNYSeNzO/TatMv41uvQgbUS3yYfLI8tOeXmu8tlI4dfioYdWAguSuwbzHuhBs4juyqEMzZYgf+g+TRWbw== X-Received: by 10.129.124.130 with SMTP id x124mr27705857ywc.101.1475103643013; Wed, 28 Sep 2016 16:00:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.18.213 with HTTP; Wed, 28 Sep 2016 16:00:42 -0700 (PDT) In-Reply-To: References: From: Ultima Date: Wed, 28 Sep 2016 19:00:42 -0400 Message-ID: Subject: Re: zpool (online|replace|labelclear) issues, -f option also failing To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 23:00:44 -0000 > Hi, > As a start you can use these in /boot/loader.conf to prevent the confusion about gptid or disk_ident. I disabled gptid at my computer. But if > I understand you would like to disable disk_ident. For ZFS it should not matter what you use. > $ sysctl kern.geom.label > kern.geom.label.disk_ident.enable: 1 > kern.geom.label.gptid.enable: 0 > kern.geom.label.gpt.enable: 1 > kern.geom.label.ufs.enable: 1 > kern.geom.label.ufsid.enable: 1 > kern.geom.label.reiserfs.enable: 1 > kern.geom.label.ntfs.enable: 1 > kern.geom.label.msdosfs.enable: 1 > kern.geom.label.iso9660.enable: 1 > kern.geom.label.ext2fs.enable: 1 > kern.geom.label.debug: 0 Thanks for that, this would probably work, but I don't understand why it would change in the first place. I know that when it occurred it was offline and I think it came back online when the system was rebooted. I'm not positive tho. My guess is the scan found it on diskid before dptid, but then why is gptid first for the others? I'm just going to replace the drive with itself with gptid because I'v already wiped some data with dd. (even tho a scrub would prob be good enough) > Further. Does ZFS see 14989197580381994958 and gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 as the same disk? Zpool replace also has an option to replace the disk 'with itself'. Just provide it one parameter like this: > # zpool replace tank 14989197580381994958 > or > # zpool replace tank gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 > Does that help? I actually didn't realize this. However the same error persists. # zpool replace tank gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification the following errors must be manually repaired: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' # zpool replace -f tank /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification the following errors must be manually repaired: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' > Oh, while I read your mail again. You have 2 GB swap configured on the disk so wiping 2MB at the start of the disk does not wipe the freebsd-zfs metadata of the da14p2 partition. Try wiping 3GB from the start and end of the disk and repartition it. Thanks for pointing this out! It would probably help if the correct area on the disk is wiped. Although it still seems that labelclear isn't up for the task. I really think the force (-f) flag needs a bump in power (for both replace and labelclear). Am I misunderstanding the use for the labelclear command? It clears the label that zdb will show for possibly similar circumstances that i'm encountering? # zpool labelclear -f gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is a member (ACTIVE) of pool "tank" Apologies, I failed to mention labelclear in my original post. It is providing similar output as the replace command. As the device is offline from the pool. Is this the correct behavior to show being an (ACTIVE) member of the pool? After wiping the correct area on the disk via dd, the replace successfully added the drive back to the pool! Thanks for pointing out my error. Thanks for taking a look at this Ronald and Allan! Ultima