From owner-freebsd-hackers@freebsd.org Tue Jan 31 00:06:31 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 0861DCC7DD6 for ; Tue, 31 Jan 2017 00:06:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5h.cmail.yandex.net (forward5h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9858E1B84 for ; Tue, 31 Jan 2017 00:06:30 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [IPv6:2a02:6b8:0:801::ab]) by forward5h.cmail.yandex.net (Yandex) with ESMTP id B03E9211C0; Tue, 31 Jan 2017 03:06:27 +0300 (MSK) Received: from smtp1j.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp1j.mail.yandex.net (Yandex) with ESMTP id 6C58A3C80D2E; Tue, 31 Jan 2017 03:06:25 +0300 (MSK) Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Lo2psWsH40-6P6us2Zg; Tue, 31 Jan 2017 03:06:25 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1485821185; bh=hr3i/yNPznrzlZxX58ZZeCM4Sf2sOkdUcVURLw85h0k=; h=Subject:To:References:Cc:From:Message-ID:Date:In-Reply-To; b=APb8iI6ybpOXk9ETO1JZfqFXjCVsa9ryXDevYx/6tuA4+twf5xdg3IpVtn3e7PNyr 0beQNR3jzDBGBBeXWiIF2SUC1pSXlbMCrNH8KshGgjRNrBwZrw+jzmOpJDx0sB3Gdv NDLyA99+hfTOIFkV5/+nEoRpY6JmWYi9PUmHtNvA= Authentication-Results: smtp1j.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0 Subject: Re: How to safely remove rest of GTP? To: Warren Block References: <20161230124407.GN37118@zxy.spb.ru> <1793b0ec-3a86-5c9a-b275-aa93cd9d230e@yandex.ru> Cc: Slawa Olhovchenkov , freebsd-hackers@freebsd.org From: "Andrey V. Elsukov" Message-ID: <37c200a6-e2b3-6f5e-792d-4464d2e5ecae@yandex.ru> Date: Tue, 31 Jan 2017 03:05:12 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 31 Jan 2017 00:06:31 -0000 On 31.01.2017 02:21, Warren Block wrote: > 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." I'm sure this is not true. GEOM_PART has several probe priorities. If there is valid MBR, GPT will not have a chance to print messages about corrupted tables. Look at this example: # truncate -s 100m disk # mdconfig -f disk md0 # gpart create -s gpt md0 md0 created # gpart add -t freebsd-boot -s 128k md0 md0p1 added # gpart show md0 => 40 204720 md0 GPT (100M) 40 256 1 freebsd-boot (128K) 296 204464 - free - (100M) # dd if=/dev/zero of=/dev/md0 count=2 2+0 records in 2+0 records out 1024 bytes transferred in 0.304545 secs (3362 bytes/sec) # gpart show md0 => 40 204720 md0 GPT (100M) [CORRUPT] 40 256 1 freebsd-boot (128K) 296 204464 - free - (100M) # dmesg | grep GEOM GEOM: md0: the primary GPT table is corrupt or invalid. GEOM: md0: using the secondary instead -- recovery strongly advised. Now let's write the MBR: # dd if=/boot/mbr of=/dev/md0 1+0 records in 1+0 records out 512 bytes transferred in 0.033823 secs (15138 bytes/sec) # gpart show md0 => 9 204791 md0 MBR (100M) 9 204791 - free - (100M) # mdconfig -du 0 # mdconfig -f disk md0 # dmesg | grep GEOM # gpart show md0 => 9 204791 md0 MBR (100M) 9 204791 - free - (100M) > 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. It is impossible to have two GEOM_PART's geoms on the same provider. > 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." There is no need to add such "partial destroy", it still always destroys GEOM. It always destroys partition table metadata. The proposed patch only adds additional check. Since GPT has two parts of metadata, it checks, that each part of metadata is valid before wipe them. > 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. As I said, in this case MBR will have higher priority and there will no GPT, until you destroy MBR. After that GPT will appear. And you will be able correctly destroy GPT using 'gpart destroy -F'. -- WBR, Andrey V. Elsukov