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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118114453.ga18...@master.debian.org