Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Jul 2022 17:09:58 -0400
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-arm@freebsd.org
Subject:   Re: Partition layout of ARM SD card images
Message-ID:  <512e33ac-1165-61c2-62b9-717a67676873@denninger.net>
In-Reply-To: <YssxIgm/ulr0%2Bp4L@phouka1.phouka.net>
References:  <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com> <YssxIgm/ulr0%2Bp4L@phouka1.phouka.net>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.

--------------ms010009010807030404090104
Content-Type: multipart/alternative;
 boundary="------------7ajbfWPEyo0TIK0QGGZzvuwI"

--------------7ajbfWPEyo0TIK0QGGZzvuwI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.)

I align partitions for them in my Crochet builds on 4m boundaries (I do 
not care about wasting a few megabytes per *partition* or filesystem 
slice).  Yes, I know 4m is overkill (1m is probably more than sufficient 
for current cards) but I prefer not to screw with this in the future as 
card capacity continues to go up, and it both has and does, and I know 
of no way to get the *physical* block size that the controller on the 
card is actually using (what it presents to the interface is not 
necessarily what it uses internally.)

I have a number of devices that boot from these cards and then run from 
RAM, and if I update something in the booted area (e.g. "mount -o rw /; 
copy something-from-here-to-there; mount -o ro /") the time for that 
second command to come back if I do NOT align the partitions is often 
tens of seconds .vs. a second or two if I do.

That's a pretty solid indication that the system is waiting for the 
controller on the card to do the read/reallocate/re-write thing and its 
not real happy with what I just asked it to do. Thus I always align them.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------7ajbfWPEyo0TIK0QGGZzvuwI
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 7/10/2022 16:05, John Kennedy wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:YssxIgm%2Fulr0+p4L@phouka1.phouka.net">
      <pre class="moz-quote-pre" wrap="">On Sun, Jul 10, 2022 at 04:26:02PM -0300, Dr. Rolf Jansen wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">... 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.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
  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.
</pre>
    </blockquote>
    <p>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.)<br>
    </p>
    <p>I align partitions for them in my Crochet builds on 4m boundaries
      (I do not care about wasting a few megabytes per *partition* or
      filesystem slice).  Yes, I know 4m is overkill (1m is probably
      more than sufficient for current cards) but I prefer not to screw
      with this in the future as card capacity continues to go up, and
      it both has and does, and I know of no way to get the *physical*
      block size that the controller on the card is actually using (what
      it presents to the interface is not necessarily what it uses
      internally.)<br>
    </p>
    <p>I have a number of devices that boot from these cards and then
      run from RAM, and if I update something in the booted area (e.g.
      "mount -o rw /; copy something-from-here-to-there; mount -o ro /")
      the time for that second command to come back if I do NOT align
      the partitions is often tens of seconds .vs. a second or two if I
      do.</p>
    <p>That's a pretty solid indication that the system is waiting for
      the controller on the card to do the read/reallocate/re-write
      thing and its not real happy with what I just asked it to do. 
      Thus I always align them.<br>
    </p>
    <p>
    </p>
    <div class="moz-signature">-- <br>
      Karl Denninger<br>
      <a href="mailto:karl@denninger.net" class="moz-txt-link-freetext">karl@denninger.net</a><br>
      <i>The Market Ticker</i><br>
      <font size="-2"><i>[S/MIME encrypted email preferred]</i></font></div>
  </body>
</html>

--------------7ajbfWPEyo0TIK0QGGZzvuwI--

--------------ms010009010807030404090104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk
YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB
MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz
NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX
MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW
ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B
3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI
XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi
WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb
NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM
qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5
CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l
y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY
2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE
MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV
HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD
bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV
HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ
MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5
c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz
dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs
QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj
7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn
3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6
Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g
3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG
7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp
mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi
Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y
W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c
5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit
oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx
GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl
MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO
XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0yMjA3MTAyMTA5NThaME8GCSqGSIb3DQEJBDFCBECz0ZfXzFbytnDZSQas
pD8NwgDiAFzO+/+2lRqxP2IuoFPSecqH2n3410bqD9s77RfbLtx0TsVEcyeHTgE93NuVMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ
MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw
IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d
Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y
aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg
Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgBj33eE7/Lyo7c/2VjjlDqiTIMyVSDBtyHpySTH
zrbJGJwA6B4y9seTAZj1Uagm0bdtPGPchQm5BbIt0CHwen2OVhTfUBI82g6orDOoKaB6zdYg
m9JCiONQsrxJkWxBe+q+FNJT6Y0ZuqQd1vdl2Y9UE0yNGQDtiIlR+jfPkDDpf4ReAMsMM6+D
Ytnc4we29jr0c9V1etZwxQgS9ZWzvj1O88c0Q89g3W7ix4RfcD9IvaWrZ9sviN8WU5NI7M61
3aBzkxgwT7z4k1JwPF3g4tp7glVGKCVO5DipibKVZt0jqLPlCrXLmDIkSolnVh33GV2FumTt
fcaO7zjEnIETa7xyrcHmUvQOXddGYJqrBfBJ8KmZziECyKhjuNV6DcDhskZgWVy5CXaCAUBt
7z3cOXeNNUkKdVVQTL8I1hXbu1m7jIxDl0s79ygEw6PW9mLtnPZFRun1jPZkoUM4ldvFtVHk
KQJELT2Ug1Gej5kHD6oP0HzlT4hRDXBXj40CAm207/ls3PGo4O7GYSBlNSBKWF7kKeqC2x4N
so/bptJK7bEo9JL2N8tDE3+L63mLp01GawOMcKRVullzZBTwrlGXTlW7ADuHkdnNvem9aFfD
f+v0mxbpV9IGSVr3o31rIUbRzM/gaJALvV61lR1ODrkom2Z/WOuFBRvukqZr7/YBHubFCQAA
AAAAAA==
--------------ms010009010807030404090104--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512e33ac-1165-61c2-62b9-717a67676873>