Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Thu 10 Sep 2020 at 16:15:05 (-0700), David Christensen wrote:
> On 2020-09-09 23:02, David wrote:
> > On Thu, 10 Sep 2020 at 11:26, David Christensen <dpchrist@holgerdanske.com> wrote:
> > > On 2020-09-09 08:03, David Wright wrote:
> >
> > > > ... having been bitten by
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561
> >
> > > I have a 300 GB drive that has been causing me some confusion. Did I
> > > elicity the bug when I partitioned the disk as follows?
> >
> > I have not read all relevant messages, but in case it helps you can
> > check your exact device partition boundaries by running:
> >
> > parted /dev/disk/by-id/ata-ST3300622AS_******** 'unit compact print
> > free unit s print free unit b print free'
>
> That parted(8) incantation has issues, as does the disk:
[…]
> This is how I invoke parted(8):
>
> 2020-09-10 14:01:58 root@tinkywinky ~
> # parted /dev/disk/by-id/ata-ST3300622AS_******** unit s print free
> Error: The backup GPT table is corrupt, but the primary appears OK, so
> that will be used.
> OK/Cancel? ok
> Model: ATA ST3300622AS (scsi)
> Disk /dev/sdb: 586072368s
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
>
> Number Start End Size File system Name Flags
> 34s 2047s 2014s Free Space
> 1 2048s 586072063s 586070016s ext2 ********
> 586072064s 586072334s 271s Free Space
I don't know what might have got your disk into this state, but
I'm happy that you got it fixed. My own strategy would have been
to use gdisk (my preferred partitioning program) to rewrite the
backup table from the main table (command r for the recovery menu,
then d).
> Looking at the above information, my first partition starts at sector
> 2048 and ends at sector 586072063 (inclusive). Both of these values
> represent 1 MiB alignment, so it appears that the partition has not
> been affected by bug 923561.
I don't think the bug affects ordinary 512/512 disks, but only
Advanced Format ones with larger block sizes, and then only if
"they" also supply an erroneous I/O value, eg:
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
It's possible that this only occurs with USB disks, too.
The partition can be 1MB aligned, but cryptsetup is fooled into
setting the wrong alignment, eg:
device-mapper: table: 254:1: adding target device sdb2 caused an alignment inconsistency:
physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920
which was produced by this partition:
/dev/sdb2 1302349824 1953521663 651171840 310.5G c W95 FAT32 (LBA)
>>> 1302349824/2048
635913.0
>>>
So, as my notes show, for the simple life, I always create
partitions with 2MB alignment regardless of future use¹,
and always add --align-payload 2048 to my cryptsetup
commands. This option is benign because it's the default
when the kernel doesn't supply a value. The man page says
to prefer --offset, but as I know nothing about what any
of these options actually do, I don't use --offset just
because there's no default value given for it. (I suspect
it may be the same as for --align-payload.)
¹ I don't worry about the initial BIOS boot partition.
Cheers,
David.
Reply to: