Date: Fri, 23 Apr 2010 08:36:05 +0400 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Andriy Gapon <avg@icyb.net.ua> Cc: Marcel Moolenaar <marcel@FreeBSD.org>, freebsd-geom@FreeBSD.org Subject: Re: [patch] resize and recover support for GPART GPT scheme Message-ID: <4BD123B5.1020506@yandex.ru> In-Reply-To: <4BD0B731.7060902@icyb.net.ua> 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> <4BD0B731.7060902@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23.04.2010 0:53, Andriy Gapon wrote: >> 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. Schemes that do not support recovery will return ENOSYS. Currently `gpart recover` will write metadata each time when user calls it. To prevent this behavior needed something similar ENOTNEEDED :) >> 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. Actually this was an implementation of `reinit` verb, but after some thinking i decided to make it as `recover` verb. And in this case using AlternateLBA is not needed. At this time it may be usable only for reporting that secondary table is not located at the last LBA. > Just to be sure - it handles the case when primary table is corrupt but the > secondary (at the end of media) is OK? Yes. > I will try to fully review your patch a little bit later. Thank you, but i still wait what Marcel will say about this patch and several others. -- WBR, Andrey V. Elsukov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD123B5.1020506>