Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Feb 2012 23:38:37 +0200
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Hiroki Sato <hrs@FreeBSD.org>
Cc:        wblock@wonkity.com, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd-stable@FreeBSD.org, freebsd@jdc.parodius.com
Subject:   Re: New BSD Installer
Message-ID:  <4F3EC8DD.6040500@FreeBSD.org>
In-Reply-To: <20120217.232843.2212672671663755444.hrs@allbsd.org>
References:  <CAOjFWZ5EhGFr_Vp0%2BTRfxvgm6KZxv9QO3UfVdKurA96z3axDMQ@mail.gmail.com> <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org> <20120217.232843.2212672671663755444.hrs@allbsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

on 17/02/2012 16:28 Hiroki Sato said the following:
> Andriy Gapon <avg@FreeBSD.org> wrote in <4F3E3000.9000206@FreeBSD.org>:
> 
> av> -----BEGIN PGP SIGNED MESSAGE----- av> Hash: SHA1 av> av> on 17/02/2012
> 09:04 Hiroki Sato said the following: av> > No, the issue is our gptloader
> assumes the backup header is always located av> > at the (physical) last
> sector while this is not mandatory in the UEFI av> > specification. av> av>
> Are you sure?
> 
> Yes, sure.  In the gm0->md0+md1 case, the last LBA of the "device" is 
> changed (growed in size) but they can still have a valid backup header at
> "the last LBA - 1" before an attempt to grow the size of the volume as the
> last paragraph of your excerpts says.  If we *choose* to grow the device
> size permanently, the backup header must be relocated at the new last LBA.
> However, before the relocation happens, the specification says both the
> primary and secondary header must be valid in the previous device size.
> This is my understanding.

No, not before the relocation, but before the resizing.
The specification just tries to protect against unexpected situations during
the resizing, which otherwise should be a quick "almost-atomic" operation.

> This means software should assume the device size can grow and should not
> assume the backup header is always located at the last possible LBA on the
> device.  If AlternateLBA does not match "the device size - 1", the software
> should recognize the location of the backup header based on the information
> in the primary header first.

Nowhere in the specification this requirement is placed on software.  The
specification is quite explicit in using the word "must" when referring to the
placement of the backup header at the last LBA.

I don't follow your suggestion of putting FreeBSD into a position of
permanently living "in the moment" between now and potentially resizing the
volume in the undetermined future.

And just in case:
Unified Extensible Firmware Interface Specification Version 2.3.1, Errata A
September 7, 2011 says:
[snip]
> Two GPT Header structures are stored on the device: the primary and the 
> backup. The primary GPT Header must be located in LBA 1 (i.e., the second 
> logical block), and the backup GPT Header must be located in the last LBA 
> of the device.

I can not see any ambiguity or openness to interpretation in this paragraph.

- -- 
Andriy Gapon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPPsjdAAoJEHSlLSemUf4vdlgIAK+iYLdNKK+ICREBcADHwdrN
vzht66LRhgghZAfiJ3ZYmWnV2dLcy1c2y676L2dRu+BKBEaS26sEKinieUAIVpaI
L3H/Wer8du9ywkTzZ+wBIo6aHOhxn+/Aj7dTDr9nUj7aNBY0pQbTqNLZfqSkrrUB
2y/oy1dCrw8J4VQnRXPhsieG7e4NHVvHzKLNfT9ShduuBd8jBBPDneZvXoZcBh0z
x9wDmBMshVISVz53s9mQGKQ2+nKTX9Y1dtCEHOOYmmRHWWWfFru8ABN7/F6lJA3p
UPEQU6UUfIFYNKf5g4mz5pOcOMfagNFmCAlZnso/DSIV6DaGj0b4Sn/oI0hf9eM=
=/R4S
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3EC8DD.6040500>