Re: RFC: future size of embed area in partition labels
On Sat, Nov 13, 2010 at 10:48:31PM +0100, Robert Millan wrote:
> 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.
As a point of information, it's not just about Windows compatibility.
Optimal alignment is valuable for performance on many modern drives.
Cylinder alignment used to be a performance win but hasn't been needed
for (I believe) decades. If you align to 2048 sectors (1MiB) then you
ensure optimal performance across a wide variety of drives, which means
that the likelihood of having to adjust partitions when migrating
between drives is reduced.
While it so happens that Windows uses 1MiB alignment by default
nowadays, my understanding is that Microsoft made that change for
essentially the same reasons we're making it. Thus it isn't really
accurate to paint it as a matter of compatibility.
(GNU Parted's NEWS file gives essentially the same reason, and does not
mention Windows.)
> 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).
If you can reproduce this, please attach installation logs, particularly
/var/log/partman. This should not generally happen as of partman-base
141 (2010-04-27).
(Obviously, we can only control the size of the embedding area when
we're creating the partition table from scratch; trying to move existing
operating systems around transparently is bad karma. I trust you're not
talking about situations where the partition table already exists.)
> - 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)
Windows' policy, as I understand it, is to support GPT only when booting
from UEFI, which is only supported in Windows 64. As we both know, GPT
systems can be booted using BIOS, although they do rely on the
protective MBR to do so, and you have to ensure that the BIOS Boot
Partition resides below 2TiB (which partman does not currently validate,
although it will create it that way unless the first 2TiB of the disk
are already in use). From talking to BIOS vendors, nobody really seems
quite sure whether INT 13 Function 42 et al actually work portably with
64-bit addresses the way they're supposed to - although of course this
holds regardless of the partition table type you're using.
Anyway, that's mostly by the by. I think our current policy of using
GPT by default only when it's necessary (UEFI, or the disk size exceeds
2TiB) is OK, really. Being more aggressive just courts problems when
they aren't necessary (when you make a big change that isn't strictly
necessary, people blame any new problems on the change even if they
would have had other problems without it, sadly), and I think we're
getting a reasonable amount of GPT testing even today.
> - 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
This feels like overkill, and in any case I think it would just shuffle
the problem around.
> - Increase minimum alignment in parted to 2048
> Pros:
> - Simple fix.
> Cons:
> - Unwanted side effects.
> - Temporary kludge.
This seems wrong. partman should only ever tell libparted to use
minimal alignment if you explicitly instruct it to do so using
preseeding (and it's a fairly obscure and new template so I doubt it is
in widespread use). Sometimes people need to use cylinder for
particular compatibility reasons; it's not the default and I wouldn't
like us to make a change that prevented them from doing this because it
is sometimes genuinely necessary.
Let's just dig into the reason why the embedding area is small in the
cases you've seen. I suspect that it may just be a simple bug, and
won't require policy changes to fix.
--
Colin Watson [cjwatson@debian.org]
Reply to: