Re: RFC: future size of embed area in partition labels
2010/11/18 Colin Watson <cjwatson@debian.org>:
> 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.
Thanks for the information, I stand corrected.
> (GNU Parted's NEWS file gives essentially the same reason, and does not
> mention Windows.)
Ah well, I got the wrong impression by reading the comments in
source code (see libparted/labels/dos.c).
> 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).
Ack. I will try. I wasn't aware this was already considered a bug.
> (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.)
Yes and no. ISTR if the partition table already exists, BUT user
requested to use "the whole disk" for installation, the result is
still a small embed area. I'll recheck.
> Windows' policy, as I understand it, is to support GPT only when booting
> from UEFI, which is only supported in Windows 64.
A huge mistake if you ask me, but well, it's their problem. It
just bothers me that this will artificially push EFI after it failed
to gain acceptance by its own merit during the last 10 years.
> 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
It probably doesn't in many cases (I remember having to patch
bochsbios back when doing my first bigdisk support tests).
Anyway this isn't a problem specific to 16-bit firmware. EFI is
sometimes seen as the panacea and in reality it's just another
buggy blob with a different interface. We already work around
some of its bugs and we'll hit those limits there too.
> (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.
Good point.
> 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.
I'm short on time currently but I'll hopefully be able to do this
before the release.
Thanks
--
Robert Millan
Reply to: