Date: Thu, 22 Apr 2010 23:53:05 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: Marcel Moolenaar <marcel@FreeBSD.org>, freebsd-geom@FreeBSD.org Subject: Re: [patch] resize and recover support for GPART GPT scheme Message-ID: <4BD0B731.7060902@icyb.net.ua> In-Reply-To: <4BD03472.6030201@yandex.ru> References: <B814515407B5445092FD63116EA3DA6B@neo> <4BCEE9E2.6010007@yandex.ru> <4BCEEC66.1080804@yandex.ru> <4BCEEF06.8010203@icyb.net.ua> <4BCEF5F8.6090102@yandex.ru> <4BCF04C7.1050701@icyb.net.ua> <4BD03472.6030201@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
on 22/04/2010 14:35 Andrey V. Elsukov said the following: > On 21.04.2010 17:59, Andriy Gapon wrote: >> I also think that this recovery mechanism is needed. >> In short: >> recover - re-create secondary table based on primary table >> reinit - relocate secondary table to a new position and update offsets >> in both >> tables accordingly > > I implemented 'recover' verb. I changed detection algoritm in GPT scheme. > Now when primary GPT header is valid reading of second header will be > done from alternateLBA offset (which read from GPT header). > When primary header is invalid reading of second header will be from the > last medium's LBA. > > And now the following scenario works: > ==================================================================== > # dd if=/dev/zero of=./d.img bs=1m count=100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 2.895854 secs (36209560 bytes/sec) > # mdconfig -f d.img > md0 > # gpart create -s gpt md0 > md0 created > # gpart add -t freebsd-zfs md0 > md0p1 added > # gpart show md0 > => 34 204733 md0 GPT (100M) > 34 204733 1 freebsd-zfs (100M) > > # mdconfig -du 0 > # dd if=/dev/zero of=./d.img bs=1m count=50 seek=100 > 50+0 records in > 50+0 records out > 52428800 bytes transferred in 1.175911 secs (44585689 bytes/sec) > # ls -lh d.img > -rw-r--r-- 1 root wheel 150M 22 Сав 14:56 d.img > # mdconfig -f d.img > md0 > # dmesg | tail -2 > GEOM: md0: the secondary GPT table is corrupt or invalid. > GEOM: md0: using the primary only -- recovery suggested. > # gpart show md0 > => 34 204733 md0 GPT (150M) > 34 204733 1 freebsd-zfs (100M) > > # gpart recover md0 > md0 recovered > # gpart show md0 > => 34 307133 md0 GPT (150M) > 34 204733 1 freebsd-zfs (100M) > 204767 102400 - free - (50M) > > # gpart resize -i 1 md0 > md0p1 resized > # gpart show md0 > => 34 307133 md0 GPT (150M) > 34 307133 1 freebsd-zfs (150M) > ==================================================================== > > There are several things that can be do where i need suggestions. > 1. What code should do when user doing `gpart recover` for scheme > that doesn't need recovering? Do you mean the schemes that do not support recovery (like MBR)? The answer is obvious. If you mean GPT in OK state, when both copies are correct, then the code could just return success and, perhaps, some diagnostic message. > 2. Probably there are needed some checks before changing metadata in > g_part_gpt_recover method. > > So, patch attached and comments are welcome. Without deep analysis the patch looks good. Just to be sure - it handles the case when primary table is corrupt but the secondary (at the end of media) is OK? I will try to fully review your patch a little bit later. Thanks a lot! -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD0B731.7060902>