RFC: future size of embed area in partition labels

[Robert Millan <rmh@debian.org>]

With the introduction of ZFS support in D-I, an existing problem with
size of embed area in partition labels begins to manifest.  This
problem is not specific to ZFS, it affects any filesystem when its
readonly implementation in GRUB reaches certain size.

When using MSDOS labels, an embed region (empty space)
before first partition was usually reserved.  This used to be
62 sectors, which is enough for most filesystems (and GRUB
developers have worked hard to ensure our filesystem code
fits in that space).  Recently, Parted developers increased
what Parted considers "optimum" alignment to 2048 (due to
Windows Vista compatibility problems I don't really care about),
and as a result in the default layout the embed region has
grown to almost 1 MiB, which is more than enough for GRUB.

Unfortunately this "optimum" alignment is not always used.
Under certain conditions a "minimum" alignment of 1, or
the usual "cylinder" alignment of 63 take place (I'm unsure
which are these, although I've been able to reproduce
the problem. But this isn't relevant, what matters is that
this logic is present in parted and partman-base).

ZFS already has surpassed the 62-sector limit, not by a
lot, but as it grows in complexity it'll be increasingly harder
to make it fit.

I expect we will eventually hit the same problem with other
next-generation filesystems which are still under development,
such as Btrfs or Hammer.

To summarize: we're getting closer to a point in which embed
area size will need to be increased, and this increase is
already necessary for ZFS.

I propose a number of different solutions.  This list covers
the approaches I could think of, but isn't exhaustive.

- Switch to GPT as default partition label
  Pros:
  - Modern design, with metadata redundancy, checksums,
    partition limit higher than 4 (no need for "extended"
    kludge).
  - We're moving to GPT anyway when disks surpass 2 TiB,
    doing it now ensures wider testing before the codebase
    that will have to deal with this is released.
  Con:
  - Lack of compatibility with old operating systems
    (even modern versions of Windows are unable to boot
    from a GPT disk AFAIK)

- Modify partman-auto to include embed space explicitly in
  its recipes.
  Pro:
  - embed space is visible to user
  Con:
  - embed space is visible to user

- Increase minimum alignment in parted to 2048
  Pros:
  - Simple fix.
  Cons:
  - Unwanted side effects.
  - Temporary kludge.

-- 
Robert Millan