On Aug 25, 2014, at 12:48 AM, Andrey V. Elsukov <bu7c...@yandex.ru> wrote:

> On 25.08.2014 03:55, Marcel Moolenaar wrote:
>>> Though, w/ people dd'ing images onto disks, and using growfs to grow
>>> as necessary, we might want to allocate a few more more than the
>>> minimum...  I do agree that we want to keep sizes to a minimum...
>> One thing I can maybe do is simply fill the empty sectors
>> that are there because of alignment. If you add -P 4K to
>> mkimg, then the first partition will by 4K aligned and you
>> have about 5 sectors unused between the end of the GPT
>> table and the first sector of the first partition. I may
>> as well extend the table to cover those unued sectors.
> IMHO, mkimg should behave like gpart and create images in
> gpart-compatible way.

It already does. There's s difference between behaving
like something else or behaving exactly identical to
that something. The same applies to compatible. It is
not the same as identical.

There is no compatibility issue. mkimg follows the GPT
specification (modulo bugs) and gpart happily groks the
partition table.

> Some users may want to copy the partition layout
> from the image to real hardware and they will not be able to do it.

I'm inclined to say that generally speaking this is not
possible. The GPT has metadata in the first few sectors
*and* the last few sectors and LBAs of these sectors are
part of the metadata. You cannot blindly copy an image
onto a physical medium unless the image and the physical
medium are of exactly the same size. Odds are they are

To reliably transfer or convert an image (e.g. RAW->VHD)
one must modify the image as part of the process. Not a
hard rule, but best to assume as a rule of thumb. This
seems to warrant a utility all by itself.

> Also, now FreeBSD 11.0 uses different first usable LBA. By default it is
> 4k aligned. And this creates some incompatibility with older versions.
> You can't do `gpart restore` and get the same table, as you had on older
> system.

It sounds restore is broken then. The restore command
cannot ever assume anything about the GPT. Including
the tool that created the GPT. In order to restore a
GPT, it must be properly backed-up. The backup header
and table should suffice most of the time for that
purpose as it's a replica, but as soon as meta-data is
missing and the restore command has to guess, things
will go wrong.

Marcel Moolenaar

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to