On Mon, 16 Dec 2013 23:12:35 -0500 (EST), Stephen Powell wrote: > > ... > my existing disk partitions, created by the Debian installer, > look like this: > > # parted /dev/i2o/hda unit s print free > Model: I2O Controller (i2o) > Disk /dev/i2o/hda: 286748672s > Sector size (logical/physical): 512B/512B > Partition table: msdos > > Number Start End Size Type File system Flags > 63s 2047s 1985s Free Space > 1 2048s 194559s 192512s primary ext3 boot > 194560s 196605s 2046s Free Space > 2 196606s 162306302s 162109697s extended > 5 196608s 17772543s 17575936s logical linux-swap(v1) > 6 17774592s 56834047s 39059456s logical ext3 > 7 56836096s 64647167s 7811072s logical ext3 > 8 64647231s 162306302s 97659072s logical ext3 > 162306303s 286748671s 124442369s Free Space > > # > > As you can see, something, somewhere, has done a number on me. The only > boundary requirement is that the starting sector be a multiple of 8 to make > 4096-byte boundaries. So why start the first partition at sector number > 2048? The only intentional free space is the free space at the end of the > disk. The other free space entries were added by the partitioning program. > And for what purpose? This is not a GPT disk, so no BIOS boot partition > needs to be created for GRUB. (I'm not even using GRUB, I'm using LILO. > But the Debian installer would not have known what boot loader I planned > to use during the disk partitioning phase. It would, however, have known > that this is an MBR disk, not a GPT disk.) Furthermore, this is not a > UEFI-based system, so no EFI System partition (ESP) needs to be created > either. So why did the Debian installer leave these two free spaces before > and after my first partition? (Apparently, sectors 0-62 are considered part > of "meta data" and are therefore not included in the leading free space.) > > Also, as you can see, the start of the next partition is not just one sector > number higher than the end of the previous partition. In the case of adjacent > logical partitions inside the extended partition, I realize that it must > leave room for an Extended Boot Record before each logical partition, but it > leaves way more room than that would require. Can you (or anyone) explain > why this wasted space has been built in?
OK, with some data analysis and some trial-and-error experimentation, I think I have figured this out. For the benefit of others on the list who might be wondering the same thing as me, here's the answer. First of all, all the primary and logical partitions listed above were created by the Debian installer during installation, presumably by using parted, except for the last partition, partition number 8, which was created manually by me using fdisk. The partitions created during installation all have a size which is an integral multiple of 1 MiB (2**20) bytes, which is 2048 512-byte sectors, and they are all allocated on a 1 MiB boundary (a sector number which is an integer multiple of 2048). The sectors are numbered beginning with 0 for this purpose. Apparently, this is deliberate on the part of either the Debian installer or parted. I assume the former. This would make sense in the general case, so that the partitions would work well for any SSD's erase block size, as long as it isn't more stringent than 1M. The first partition, partition number 1, cannot be allocated starting with sector number 0, since that is the Master Boot Record (MBR). So it is allocated starting with the next higher multiple of 2048, which is of course 2048. Partition number 2 is the extended partition. I'll come back to that. The next partition, partition number 5, is a logical partition. If it were a primary partition, it could be allocated starting with the next sector after the last sector of partition number 1, since that is a 2048-sector boundary. But it isn't. It's a logical partition. An Extended Boot Record (EBR) is required after the end of partition number 1 and before the start of partition number 5. So the start of partition number 5 is bumped up to the next higher multiple of 2048. Of the 2048 sectors between the end of partition number 1 and the beginning of partition number 5, 2047 of them are unused sectors and 1 is an EBR. Partition number 2, the extended partition, starts with this first EBR. There is 1 unused sector after the EBR and 2046 unused sectors in front of it. Similarly, 2048 sectors have to be thrown in between the end of partition number 5 and the beginning of partition number 6. One of them is an EBR describing the following logical partition and 2047 of them are unused sectors. The same goes for the space between the end of partition number 6 and the beginning of partition number 7. The space between the end of partition number 7 and the beginning of partition number 8 breaks the pattern. There are 63 sectors between the end of partition number 7 and the beginning of partition number 8. One of them is an EBR describing partition number 8 and the other 62 are unused sectors. Why 63 instead of 2048? 63 is the number of sectors per track. Under the old DOS rules, DOS wants partitions to start on a track boundary. fdisk, following the old DOS rules, assumed that the previous partition ended on the last sector of a track, and put 63 sectors between the two partitions so that the next partition would start on a track boundary. Apparently, parted does not list free space between logical partitions within the extended partition, but does list free space which is outside any partition. Working as designed. Problem solved. -- .''`. Stephen Powell : :' : `. `'` `- -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2075993145.34922.1387322590883.javamail.r...@md01.wow.synacor.com
