From owner-freebsd-hackers@freebsd.org Mon Jan 30 23:21:40 2017 Return-Path: Delivered-To: freebsd-hackers@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 255E9CC8891 for ; Mon, 30 Jan 2017 23:21:40 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E09668CA for ; Mon, 30 Jan 2017 23:21:39 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id v0UNLbbW009473 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Jan 2017 16:21:37 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id v0UNLbJI009470; Mon, 30 Jan 2017 16:21:37 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 30 Jan 2017 16:21:37 -0700 (MST) From: Warren Block To: "Andrey V. Elsukov" cc: Slawa Olhovchenkov , freebsd-hackers@freebsd.org Subject: Re: How to safely remove rest of GTP? In-Reply-To: <1793b0ec-3a86-5c9a-b275-aa93cd9d230e@yandex.ru> Message-ID: References: <20161230124407.GN37118@zxy.spb.ru> <1793b0ec-3a86-5c9a-b275-aa93cd9d230e@yandex.ru> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (wonkity.com [127.0.0.1]); Mon, 30 Jan 2017 16:21:37 -0700 (MST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 23:21:40 -0000 On Mon, 30 Jan 2017, Andrey V. Elsukov wrote: > On 30.01.2017 18:55, Warren Block wrote: >>>> GEOM: da6: the primary GPT table is corrupt or invalid. >>>> GEOM: da6: using the secondary instead -- recovery strongly advised. >>>> GEOM: da22: the primary GPT table is corrupt or invalid. >>>> GEOM: da22: using the secondary instead -- recovery strongly advised. >>>> GEOM: da6: the primary GPT table is corrupt or invalid. >>>> GEOM: da6: using the secondary instead -- recovery strongly advised. >>>> GEOM: da22: the primary GPT table is corrupt or invalid. >>>> GEOM: da22: using the secondary instead -- recovery strongly advised. >>> >>> You may try attached patch, I did only basic tests, so first try >>> somewhere :) >> >> I really like the idea of gpart being able to remove the secondary GPT, >> but combining it with the existing destroy command is ambiguous. It's >> hard for the user to tell what will happen, and the command itself >> implies that it will destroy all partitioning. > > I don't see any ambiguity here. A user sees corrupted GPT, it can only > destroy or recover it. Ah, but the user might not even see it. "I wrote an MBR to my disk (with some other software) and now FreeBSD says it has a corrupted GPT." In this case, it can have a valid MBR which the user does not want to destroy. So re-using the gpart destroy command for this is ambiguous. It's also kind of dangerous, in that when the user finally does understand that "destroy" doesn't really destroy all partitioning, they might use it expecting to only destroy the "bad" partitioning and be surprised because things were not like they thought and it wiped out the "good" partitioning. Put another way: `gpart destroy -F` means "destroy the GEOM unconditionally". Adding this additional function to it makes it "destroy the GEOM, unless some specific condition, and then it means only destroy a part of it." As I think I said before, the function is really needed. It is just making the user interface unambiguous that is my concern. zfs has "labelclear". If gpart did that, along with a set amount of space to clear at the beginning and end of the drive, I'd be happy with it. It does not need to detect the type of geom. gpart labelclear -F -s1m da22 to clear the first and last 1M of da22. Maybe force the user to give the -F flag. (Yes, this can be done with dd, but slowly because of oseeking to the end of a big drive. And it requires math, which is both scary and beyond the capacity of many people to calculate.) > It is impossible to have a corrupted GPT and some > other type of partition table in the same time. Maybe when only using FreeBSD and gpart, but I'm pretty sure I've seen forum users who have tried some crappy other formatting tool and have overwritten the primary GPT with a valid MBR and left the secondary GPT untouched. This only becomes obvious when they bring the disk back to a FreeBSD system.