Date: Wed, 21 Apr 2010 21:48:16 +0400 From: Andrey V. Elsukov <bu7cher@yandex.ru> To: Andriy Gapon <avg@icyb.net.ua> Cc: Lister <lister@kawashti.org>, Marcel Moolenaar <marcel@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: Re: OCE and GPT Message-ID: <50691271872096@web136.yandex.ru> In-Reply-To: <4BCF04C7.1050701@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>
next in thread | previous in thread | raw e-mail | index | archive | help
21.04.10, 16:59, Andriy Gapon: > > providers withing scheme. But with GPT we have problem, after > > booting with bigger media size the second partition table will > > be lost. And GPT will be broken. > > Why? > Do we have it hardcoded where to look for the secondary GPT? Yes. Current implementation does search for second GPT table only at last LBA. And it violates with UEFI 2.3 specification. > I also think that this recovery mechanism is needed. > In short: > recover - re-create secondary table based on primary table Also there can be situation when primary table is corrupted, but secondary isn't. > reinit - relocate secondary table to a new position and update offsets in both > tables accordingly What should reinit do when nothing was changed? > > it was before? Should we reject this way of recovering and allow recovering > > only for the same size or bigger media size? > > I think that we could allow smaller media size _provided_ that lost space doesn't > overlap with any partitions found in primary table. Otherwise it's a data loss > scenario and a user should be left to deal with it. IMHO, of course. Current implementation rejects table where 'LastUsableLBA' is greather than last medium's LBA. This behavior also doesn't described in UEFI spec. =) I think if we will have recover and reinit verbs implemented we can change some algorithms of table detection. -- WBR, Andrey V. Elsukov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50691271872096>