On Monday 06 September 2010 12:51:46 Karel Zak wrote:
> On Sun, Sep 05, 2010 at 07:12:41PM +0300, Anssi Hannula wrote:
> > Ok, I then create the primary partition starting in sector 2048 and and
> > select
> >
> > partition size '+5500K' for a 5,5MB partition:
> > Device Boot Start End Blocks Id System
> >
> > /dev/loop0p1 2048 13047 5500 83 Linux
> >
> > Looks ok. Now, when I ask fdisk to create another partition, fdisk offers
> > to start it immediately after the end of the previous partition:
> > "First sector (13048-10239999, default 13048):"
> > Is it intended that fdisk doesn't align the default value to 14336?
>
> The begin of the (next) partition should be always aligned and
> without extra gaps between partitions. We use strictly 1MiB alignment
> for the begin of the first partition only. For the next partitions
> fdisk cares about alignment to the physical block boundary only.
OK.
> If the next LBA (the begin of the next partition) is not aligned,
> then fdisk uses 1MiB grain as a default. For example:
>
> Sector size (logical/physical): 512 bytes / 4096 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sdb1 2048 11109 4531 83 Linux
> ...
> First sector (11110-2097151, default 12288):
>
> the next sector (11110) is not aligned, so fdisk is suggesting 12288,
> this LBA is aligned to 1MiB grain and aligned to phy block boundary.
>
> Anyway, it's very unusual to use +<size>K to define partition size.
> I think it's more generic to use +<size>{M,G} and then the layout
> is always aligned without gaps.
Yes, I guess usually encountered it when specifying +<sectorcount> when
copying a partition from another disk and I wanted to create a new partition
with the exact same size. But now I know better :)
> > I've gotten bitten by this several times and I've created unaligned
> > partitions on 4k sector devices.
>
> All defaults and all +<size>{K,M,G,...} offsets should be aligned,
> but you can still explicitly define exact LBAs for begin/end of your
> partition. Fdisk is low-level tool and it assumes that you know what
> are you doing. Anyway, it prints warning for misaligned partitions.
Except for the 4k drives that lie about their physical sector size, such as
mine :)
> > I.e. what I would've expected:
>
> > "First sector (13048-10239999, default 14336)":
> Please, always copy & past the "Sector size (logical/physical):" line
> from fdisk output to your emails/bug reports.
Ok. (for the record, this was with 512/512).
> > Thirdly, I create an extended partition with one logical partition as
follows:
> > Device Boot Start End Blocks Id System
> >
> > /dev/loop0p1 2048 13047 5500 83 Linux
> > /dev/loop0p2 13048 14335 644 83 Linux
> > /dev/loop0p3 14336 10239999 5112832 5 Extended
> > /dev/loop0p5 16384 65534 24575+ 83 Linux
> >
> > Now, I wish to add another logical partition:
> >
> > "First sector (67583-10239999, default 67583):"
> >
> > fdisk suggests 67583 as the starting point, which is exactly 1MB after
> > the end of the previous logical partition, but in no way aligned. Why is
> > there such an offset, and why does it happen only with logical
> > partitions?
>
> logical partition: EBR (partition table) + partition.
>
> It means that for every logical partition you need extra space where
> is EBR. The traditional concept is to use the same offset for the
> EBR as for MBR, it means 1MiB. For more details see:
>
> http://en.wikipedia.org/wiki/Extended_boot_record
>
> The begin of the logical partition should be aligned of course. I
> guess that "67583" in your example is aligned (loop dev uses 512-byte
> sector).
>
> Now you know why GPT partition table is better ;-)
Ok, thanks for all the explanations :)
> Hint: use scsi_debug, it's better than loopdev. For example:
>
> # modprobe scsi_debug dev_size_mb=1024 sector_size=512 physblk_exp=3
>
> to create 1GiB (allocated in RAM!) disk with 4096-byte phy.sector size.
>
> Karel
--
Anssi Hannula
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
