[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to get installer to align partitions on 4096 byte boundaries?



On Apr 27, 2014, at 2:54 AM, Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Sb, 26 apr 14, 20:24:12, Rick Thomas wrote:
>> 
>> With more and more disks being manufactured with "Advanced format" 
>> (4096-byte physical-sectors) I'm wondering how I can tell the 
>> Debian-installer partitioner to align all partitions on 4096-byte (or 
>> 1 MiB for FLASH) boundaries?  Is there some parameter I can pre-seed 
>> -- or set at runtime?
> 
> The wheezy installer (at least) aligns by default to 1MiB.

I haven't been able to test this on x86 or amd64, but on powerpc64 this doesn't seem to be true.

I just did a fresh install from the Wheezy PowerPC DVD-1 on an Apple PowerMac G5.  When it got to disk partitioning, I specified "use the full disk and create LVM" with a separate LV for /home.  The following is what the partition table looks like:

root@bigal:~# mac-fdisk -l /dev/sda
/dev/sda
        #                    type name                   length   base       ( size )  system
/dev/sda1     Apple_partition_map Apple                      63 @ 1          ( 31.5k)  Partition map
/dev/sda2         Apple_Bootstrap untitled                 1954 @ 64         (977.0k)  NewWorld bootblock
/dev/sda3         Apple_UNIX_SVR2 untitled               500001 @ 2018       (244.1M)  Linux native
/dev/sda4               Linux_LVM untitled           1953023100 @ 502019     (931.3G)  Unknown
/dev/sda5              Apple_Free Extra                      49 @ 1953525119 ( 24.5k)  Free space

Block size=512, Number of Blocks=1953525168
DeviceType=0x0, DeviceId=0x0

When I say "sector" or "logical-sector" in the following I mean 512-byte sector.  When I say "physical-sector" I mean 8 logical-sectors (4096-bytes).  When I say "megabyte" or "MiB" I mean 1048576 bytes or 2048 logical-sectors, or 256 physical-sectors.

The Apple_partition_map (sda1) is fine.  It skips the 0th sector and ends on the 64 sector (8 physical-sector) boundary.

But the Apple_Bootstrap/NewWorld_bootblock partition (sda2), while it begins on a physical-sector boundary, does not end on a physical-sector boundary. A reasonable thing for the installer to do would be to make it exactly 1 megabyte long, but I'd be happy with any integer number of physical-sectors.  The openboot firmware is expecting it to be just about anything longer than 800k (100 physical-sectors / 400 logical-sectors) It doesn't know anything about physical-sectors vs logical-sectors, so as long as the simulation in the diskdrive works, so will the openboot firmware.  It only gets used when the system boots or a new yaboot.conf gets installed, so this is not critical, but it is curious.  Perhaps the installer thinks that a full MiB is too large?  I can imagine that this might be true on some of the IBM hardware, but I know it's not true for Apple hardware.  In any case...

The third partition (sda3) holds /boot for the installed Linux.  It does not start or end on a physical-sector boundary (due to the odd length of the preceding partition), though there is no reason I can think of that it needs to be that way.  Again, this partition is not used frequently, so not starting on a MiB boundary does not noticeably affect performance -- but it is odd, nevertheless.  However, there is absolutely *no* excuse for it not to *end* on a MiB boundary.  Indeed, the rather strange length seems to be chosen specifically to keep it from ending on a MiB boundary.  Curiouser and curiouser!

Now we come to the really strange one -- the Linux_LVM (sda4) partition.  There really is no excuse for it not to start on a clean MiB boundary, and every reason to assume that it should.  And yet... here we are with a starting sector that is not even a multiple of 2, let along a multiple of 2048)!

So I ask again: Aside from doing the partitioning manually, myself, is there any way to get the installer's partitioner to respect the new guidelines for "Advanced Format" and SSD/flash disks?

Thanks!

Rick

Reply to: