From nobody Sun Jul 10 21:20:05 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A40341CFBF75 for ; Sun, 10 Jul 2022 21:20:09 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lh0KN2sZPz42fX for ; Sun, 10 Jul 2022 21:20:08 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657488006; s=strato-dkim-0002; d=cyclaero.com; h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From: Subject:Sender; bh=iroWrrViGhbKmZqeVpTEKurzBgu9UQPejp6ewaxFO4c=; b=FB5hgr+GIG5vZ9y4NiYgcT8BwSA5pP+5H/yB6hRgZQp1KZzPLXpuv7keW+0sR/ft+R VoIeXIDAawQhjz8D/wuEi7AjltsxhE33Wgw5jPXwNlVKTn0gPEA+etSMNEnhVVgGuEfn e/nudhtNT3tbDycnZkquWBvRpqn6/IJo2JGPXncUqMci8c3pZF0EdqrBH7AaDlV4dRMw rsWo5Xnhz6B3k/EsIs6c/pFxfRuXTLT+SGl07nH4Px0JQsYwws5brl8xdQUUJYUA0Fva 6tQb2f/tAKz1OPBHfEcCPPfej+HlpziHKsrxmpzH8JDt7HpmW/AvSjY47le3exylZj7E +PCA== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg=" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.46.1 AUTH) with ESMTPSA id kcd9d5y6ALK6d23 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Sun, 10 Jul 2022 23:20:06 +0200 (CEST) Received: from rolf-mini.obsigna.com (unknown [177.95.254.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id C91DB63937 for ; Sun, 10 Jul 2022 23:20:05 +0200 (CEST) From: "Dr. Rolf Jansen" Content-Type: multipart/alternative; boundary="Apple-Mail=_50CFE346-C2DF-485B-8723-DA15CDB2408D" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: Partition layout of ARM SD card images Date: Sun, 10 Jul 2022 18:20:05 -0300 References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com> <512e33ac-1165-61c2-62b9-717a67676873@denninger.net> To: freebsd-arm In-Reply-To: <512e33ac-1165-61c2-62b9-717a67676873@denninger.net> Message-Id: <45F48B1C-05D3-4786-B40E-57F281FDE558@cyclaero.com> X-Mailer: Apple Mail (2.3445.104.15) X-Rspamd-Queue-Id: 4Lh0KN2sZPz42fX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=FB5hgr+G; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.25 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com X-Spamd-Result: default: False [-2.00 / 15.00]; FROM_NAME_HAS_TITLE(1.00)[dr]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24]; R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[85.215.255.25:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm]; ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[cyclaero.com:+]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[cyclaero.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_50CFE346-C2DF-485B-8723-DA15CDB2408D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 10.07.2022 um 18:09 schrieb Karl Denninger : >=20 > On 7/10/2022 16:05, John Kennedy wrote: >> On Sun, Jul 10, 2022 at 04:26:02PM -0300, Dr. Rolf Jansen wrote: >>=20 >>> ... 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 =3D 104448, which as a matter of = fact is 4k aligned (104448*512/4096 =3D 13056) and 1M aligned as well = (104448*512/1024/1024 =3D 51), however all this keeps looking strange. >>>=20 >>> Are there reasons for this partition layout besides making it look = more interesting? If yes, some insights would be good. >>>=20 >> 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. >>=20 > =46rom 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.= --Apple-Mail=_50CFE346-C2DF-485B-8723-DA15CDB2408D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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 =3D 104448, which as a matter of = fact is 4k aligned (104448*512/4096 =3D 13056) and 1M aligned as well = (104448*512/1024/1024 =3D 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.

=46rom 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.= --Apple-Mail=_50CFE346-C2DF-485B-8723-DA15CDB2408D--