On Aug 25, 2014, at 12:48 AM, Andrey V. Elsukov <bu7cher_at_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 not. 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 marcel_at_xcllnt.net
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC