Revert revision 254095
In revision 254095, gpt_entries is not set to match the on-disk hdr_entries, but rather is computed based on available space. There are 2 problems with this: 1. The GPT backend respects hdr_entries and only reads and writes that number of partition entries. On top of that, CRC32 is computed over the table that has hdr_entries elements. When the common code works on what is possibly a larger number, the behaviour becomes inconsistent and problematic. In particular, it would be possible to add a new partition that on a reboot isn't there anymore. 2. The calculation of gpt_entries is based on flawed assumptions. The GPT specification does not dictate that sectors are layed out in a particular way that the available space can be determined by looking at LBAs. In practice, implementations do the same thing, because there's no reason to do it any other way. Still, GPT allows certain freedoms that can be exploited in some form or shape if the need arises. PR: 229977 MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D19438
This commit is contained in:
parent
e846d2bb4f
commit
6ea9978207
@ -990,10 +990,9 @@ g_part_gpt_read(struct g_part_table *basetable, struct g_consumer *cp)
|
||||
|
||||
basetable->gpt_first = table->hdr->hdr_lba_start;
|
||||
basetable->gpt_last = table->hdr->hdr_lba_end;
|
||||
basetable->gpt_entries = (table->hdr->hdr_lba_start - 2) *
|
||||
pp->sectorsize / table->hdr->hdr_entsz;
|
||||
basetable->gpt_entries = table->hdr->hdr_entries;
|
||||
|
||||
for (index = table->hdr->hdr_entries - 1; index >= 0; index--) {
|
||||
for (index = basetable->gpt_entries - 1; index >= 0; index--) {
|
||||
if (EQUUID(&tbl[index].ent_type, &gpt_uuid_unused))
|
||||
continue;
|
||||
entry = (struct g_part_gpt_entry *)g_part_new_entry(
|
||||
|
Loading…
Reference in New Issue
Block a user