Re: Partition layout of ARM SD card images

> Am 10.07.2022 um 18:09 schrieb Karl Denninger <karl@denninger.net>:
> 
> On 7/10/2022 16:05, John Kennedy wrote:
>> On Sun, Jul 10, 2022 at 04:26:02PM -0300, Dr. Rolf Jansen wrote:
>> 
>>> ... The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange.
>>> 
>>> Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good.
>>> 
>>  I think there are historical reasons, probably more with not "wasting"
>> space on small SD cards (~512 byte blocks).  I haven't had it bite me
>> recently, at least, but I imagine the FreeBSD folks are trying (perhaps
>> vainly) to keep image count to a minimum.  I think I was tweaking my
>> images from RPI2 and later to 4K and 1M like you are to line up with the
>> storage I had them stored on and the filesystems inside the partitions.
>> 
> From my experience it is an EXTREMELY bad idea to NOT align SD card images; these cards are notorious for suffering from severe write-amplification problems and if you want to kill them don't align your partitions.  Never mind serious performance problems you may run into on writes.  This is true for both SD and uSD cards, but particularly the latter (e.g for Pis and similar.

This is common knowledge for more than a decade, and therefore I skipped the explanation on why this is important.

The question in the first place is why the official images, which the installation instructions tell us to copy via dd to the SD card are not aligned by 100%. However, perhaps I am missing some points regarding the internals of SD cards, of the MBR, of the Fat32 scheme. Perhaps the actual useful data here starts at an uneven block - I don't know therefore the question why, despite of the common knowledge, the partition table look strange.