树莓派上的 Oracle Linux (Btrfs)

于 2019 年 7 月 22 日

企业级功能来到微型服务器。

面向树莓派 3 的 Oracle Linux 7 已经发布。此版本将 Btrfs 打包为 UEK 品牌 Linux 4.14 长期支持 (LTS) 内核上的根文件系统。随标准 ISO 安装程序一起提供了一个带有最小安装的可引导磁盘映像。

CentOS 似乎仅支持用于 AArch64 的 “Mustang” Applied Micro X-Gene，并且为所有型号的树莓派提供较旧的 AArch32 环境。在 RPM 发行版中，Oracle Linux 是支持 Pi Model 3 的 AArch64 的一个引人注目的选择。

这并不是说 Oracle AArch64 Linux 没有缺陷，因为 Oracle 警告说这是一个“预览版，仅用于开发目的；Oracle 建议这些版本不要用于生产环境。” 非功能性 WiFi 设备缺少固件和文档，Oracle 承认这是被忽略的。映像中未包含 X11 图形，尽管您可以安装它们。同名的数据库客户端（和服务器）也缺失。Oracle 之前曾提供过孤立软件的示例，即其 Linux for SPARC 项目，该项目在两个小版本发布后被放弃。虽然 Oracle 回应说“我们的最终目标是服务器级平台”，但无法保证此 ARM 版本不会遭受同样的命运。一个可能的硬件目标是富士通 A64FX，这是一款新的服务器处理器，在一个芯片上捆绑了 48 个可寻址的 AArch64 内核和 32GB 的 RAM，据称是“最快的服务器处理器”。

Pi 上的 AArch64

您需要一台树莓派 Model 3 才能运行 Oracle Linux。3B+ 是目前最好的设备，您应该选择它而不是之前的 Model 3B 和所有其他之前的型号。Model 3 板都保留了（限制性的）1GB 内存——SODIMM 插槽会实用得多。较新的板具有速度快 200MHz 的 CPU 和千兆兼容以太网端口（由于连接它的 USB2 链路，该端口被限制为 300Mbit）。Model A 也存在，但它缺少 3B 上的许多端口。更重要的是，Model 3 平台引入了 64 位 CPU。

与其他知名的微处理器系列相比，ARM 在 64 位寻址功能方面起步较晚，于 2011 年宣布了此扩展。英特尔首次尝试将 x86 市场迁移到流产的 Itanium 64 位架构，于 2001 年发布，最终屈服于 AMD64，后者于 2003 年首次亮相。MIPS 和 SPARC 更早地完成了这种转变（1991 年和 1995 年，分别）。

尽管起步较晚，但 ARM AArch64 CPU 架构现在是主要的移动平台。所有受支持的 iPhone 现在都必须运行它，并且大多数现代 Android 设备都已迁移到它。ARM 在电源效率方面保持了竞争优势，因为其指令集意识形态和实现的巨大变化使 ARM 能够保持其在移动领域的市场领导地位。

Acorn/Advanced RISC Machine (ARM) 起始于追溯命名的 AArch32 汇编语言和机器语言，这些语言由 Furber 和 Wilson 为 Archimedes 台式计算机设计，其中巨大的电源效率“完全是一个意外”。在 ARM 诞生后的十年里，桌面性能仍然是架构的重点。

苹果公司决定将（失败的）Newton 基于 ARM，这开辟了一个新的移动设备应用市场，从而催生了一种用于超紧凑型汇编的新指令集——Thumb 1 和 2。这些指令集与 AArch32 和 AArch64 不同，它们侧重于代码密度和移动设备的最小占用空间。Thumb 2 是一种 16 位/32 位可变长度指令集，它被动态地转换为 AArch32。存在许多其他 ARM 扩展，但 Thumb 似乎在 ARM 实现中都具有很大的灵活性和持久性。

当移动设备接近 32 位 ARM 的 4Gb 内存限制时，设计人员决定打破过去。AArch32 中的主要错误早已为人所知

设计错误，例如将 r15 作为程序计数器或使每个指令都有条件，对于 CPU 架构师而不是程序员来说是问题，并且它们在 ARM 架构的 64 位版本中消失也就不足为奇了。它们肯定使实现超标量、乱序执行变得非常困难。

AArch64 中的更改使其更接近 MIPS 的精神，其中最值得注意的是

条件执行已被删除，从而促进了多个管道中的乱序处理。
R15/PC 寄存器现在只能通过少量的跳转和分支指令来操作，从而大大简化了分支预测。

这些性能改进，以及指针大小增加到 64 位，是以代码密度为代价的——为本机 AArch64 编译的程序将比 AArch32 的等效程序更大。尽管有这些增强功能，但过去十年中的大多数英特尔桌面处理器在大多数基准测试中都将轻松击败 Pi（但它们不会使用 10 瓦电源来实现这一点）。我在下面更详细地检查了 AArch64 的代码密度影响。

安装

大多数树莓派用户依赖闪存，闪存分为两个等级。多层单元 (MLC) 介质价格便宜且提供大量存储空间，但它可能会非常快速地衰减（单元通常在 5,000 次写入操作后被破坏）。大多数零售闪存介质（SD 卡、USB 闪存驱动器）都是 MLC，并且在高 I/O 使用率下寿命不长，尽管有“磨损均衡”电子设备试图将写入均匀地分布在整个设备上。单层单元 (SLC) 介质更昂贵并且提供较小的存储量，但它大大增加了写入操作次数，直到单元失效（100,000 次）。两种类型的内存都可以通过加热它们来“修复”，但这对于大多数塑料封装中的内存是不可行的。如果您预计有大量的 I/O，请计划购买正确等级的闪存。

新型号 3 的一大好处是能够从 USB 启动。标准硬盘驱动器现在是一个启动选项。SLC 介质在 USB 闪存格式中也比 microSD 卡更丰富且更便宜。选择适合您预期 I/O 使用率的格式。

一旦您选择了并获得了您的介质，您就可以下载并解压缩以下文件


$ xz -dkv rpi3-ol7.6-image-20181116.img.xz
rpi3-ol7.6-image-20181116.img.xz (1/1)
  100 %   266.4 MiB / 5120.0 MiB = 0.052  55 MiB/s   1:32

启动映像的完整大小为 5GB——您的启动介质必须至少为这个大小


$ ll rpi3-ol7.6-image-20181116.img*
-rw-r--r-- 1 root root 5368709120 Jan 13 18:52
rpi3-ol7.6-image-20181116.img
-rw-r--r-- 1 root root  279309592 Jan 13 18:52
rpi3-ol7.6-image-20181116.img.xz

插入您的启动介质并确保它被检测到，但未挂载


# dmesg | tail -3
[  378.540649] mmc0: new high speed SDHC card at address 0002
[  378.544104] mmcblk0: mmc0:0002 00000 7.83 GiB
[  378.548395]  mmcblk0: p1

最后，将映像写入到原始介质


# dd if=rpi3-ol7.6-image-20181116.img of=/dev/mmcblk0 bs=4M

假设没有写入错误，介质现在已准备好启动树莓派 Model 3。

操作

将介质加载到 Pi 中，将 HDMI 电缆连接到显示器，并连接以太网电缆。连接电源后，Pi 将启动（没有电源开关）。

Pi 可能无法使用较旧的 USB 外围设备启动。当连接了磨损严重的 IBM 89P8800 USB 1.1 键盘时，固件发出消息 Timeout poll on interrupt endpoint 并拒绝启动。尝试使用稍新的 Lenovo 41A5248 键盘，启动过程继续进行，但被大大延迟。一旦操作系统运行，这两个键盘都可以正常工作。最初启动时最好不要连接任何非必要的 USB 硬件。

启动完成后，应显示 login: 提示符。用户 root 和密码 oracle 将允许您选择新的 root 密码，然后进入 Bash。

/proc/cpuinfo 文件将列出四个处理器核心，并带有以下描述


[root@rpi3 ~]# cat /proc/cpuinfo
processor   : 0 ... 1 ... 2 ... 3
BogoMIPS    : 38.40
Features    : fp asimd evtstrm crc32 cpuid
CPU implementer   : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part    : 0xd03
CPU revision      : 4

根文件系统位于 Btrfs 上，这与您通常在 x86_64 (AMD64) 版本的 Oracle/Red Hat/CentOS/Scientific Linux 7 上看到的 XFS 不同。/boot 文件系统位于 EXT4 上，可能是由于引导加载程序方面的考虑


[root@rpi3 ~]# mount | egrep 'btrfs|ext4'
/dev/mmcblk0p4 on / type btrfs
(rw,noatime,ssd,space_cache,subvolid=5,subvol=/)
/dev/mmcblk0p2 on /boot type ext4 (rw,noatime,data=ordered)

还要注意上面的 ssd 挂载选项。Btrfs 自动检测到此选项，并且以前是不安全的，会对闪存介质的“可用性和寿命产生负面影响”，但现在在 4.14 内核中是合适的。请注意，自动检测到的 SSD 挂载选项未在 /etc/fstab 中指定（我已经删除了 UUID 和 LABEL）


[root@rpi3 ~]# sed -r 's/^(UUID|LABEL)[^ ]*[ ]*//' /etc/fstab
#Generated by RootFS Build Factory
/boot/efi vfat noatime 0 0
/boot ext4 noatime 0 0
swap swap noatime 0 0
/ btrfs noatime 0 0
tmpfs   /tmp       tmpfs   rw,nodev,nosuid,size=128M    0 0

根文件系统位于 SD 卡的 p4 分区上


[root@rpi3 ~]# fdisk -l

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes, 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000164f6

        Device Boot    Start      End   Blocks   Id  System
/dev/mmcblk0p1          2048   526335   262144    c  W95 FAT32
 ↪(LBA)
/dev/mmcblk0p2        526336  1550335   512000   83  Linux
/dev/mmcblk0p3       1550336  2074623   262144   82  Linux
 ↪swap / Solaris
/dev/mmcblk0p4       2074624  10463231  4194304   83  Linux

请注意，上面我正在 8GB SD 卡上运行，但该卡的最后三分之一未使用，因为它不在分区中。您可以添加未使用的空间到根文件系统，方法是首先扩展分区


[root@rpi3 ~]# growpart /dev/mmcblk0 4
CHANGED: partition=4 start=2074624 old: size=8388608
↪end=10463232 new: size=13449183,end=15523807

然后将 Btrfs 文件系统扩展到新分配的空间中


[root@rpi3 ~]# btrfs filesystem resize max /
Resize '/' of 'max'

根文件系统现在占据了闪存设备的其余部分


[root@rpi3 ~]# fdisk -l

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes, 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000164f6

        Device Boot  Start      End   Blocks   Id  System
/dev/mmcblk0p1        2048   526335   262144    c  W95 FAT32
 ↪(LBA)
/dev/mmcblk0p2      526336  1550335   512000   83  Linux
/dev/mmcblk0p3     1550336  2074623   262144   82  Linux
 ↪swap / Solaris
/dev/mmcblk0p4     2074624 15523806  6724591+  83  Linux

Btrfs 是一个功能非常强大的文件系统，其功能类似于 ZFS。它能够进行透明压缩、镜像、错误检测，并且具有自修复功能。（请关注未来关于深入 Btrfs 报道的文章。）树莓派上的 Oracle Linux 为许多新工具和功能提供了一个有用的学习环境，而添加 Btrfs 是其中最重要的。

在 x86_64 上的最小安装中缺少许多实用程序。不分优先顺序，其中一些是 ethtool、less、man 和 nmtui。假设与 Oracle 建立了互联网连接，yum install man 将引入 less 作为依赖项（并让您开始阅读所有 Btrfs 手册页）。yum whatprovides 命令对于搜索未安装软件包的内容以查找特定实用程序非常有用。

Busybox 是某些本机 Oracle AArch64 软件包的替代方案。那些不熟悉 Busybox 的人可以查看我之前在Linux Journal 上发表的容器文章，其中详细介绍了它的使用。 1.28.1 版本提供了 Busybox 的几个 ARM 二进制文件（如下所示）


[root@rpi3 ~]# for x in busybox-arm*
               do ls -l $x; file $x; ./$x | head -1; done

-rwxr-xr-x 1 root root 1132724 Jan 10 17:23 busybox-armv5l
busybox-armv5l: ELF 32-bit LSB executable, ARM, version 1
 ↪(SYSV)...
BusyBox v1.28.1 (2018-02-15 14:34:02 CET) multi-call binary.
-rwxr-xr-x 1 root root  836560 Jan 10 17:23 busybox-armv7m
busybox-armv7m: ELF 32-bit LSB shared object, ARM, version 1
 ↪(SYSV)...
BusyBox v1.28.1 (2018-02-15 14:34:02 CET) multi-call binary.
-rwxr-xr-x 1 root root 1079156 Jan 10 17:23 busybox-armv7r
busybox-armv7r: ELF 32-bit LSB executable, ARM, version 1
 ↪(SYSV)...
BusyBox v1.28.1 (2018-02-15 14:34:02 CET) multi-call binary.
-rwxr-xr-x 1 root root 1078504 Jan 10 17:23 busybox-armv8l
busybox-armv8l: ELF 32-bit LSB executable, ARM, version 1
 ↪(SYSV)...
BusyBox v1.28.1 (2018-02-15 14:34:02 CET) multi-call binary.

请注意，上面的 busybox-armv7m 二进制文件比所有其他文件小得多。此二进制文件显然由 Thumb 2 代码组成；ARM 7 M 和 R 架构似乎都排除了 AArch32 和 AArch64：“ARMv7-M... 不支持 ARM 指令集（仅限 Thumb）。” Thumb 可能会解释较小的尺寸，但其使用可能会以一定的性能为代价。

Oracle 包含一个 AArch64 编译器环境，但这不太可能能够发出 ARMv7-M 代码。Oracle 没有像在 AMD64 上提供 glibc.i686 那样提供 glibc.aarch32 或 glibc.thumb2 软件包，/usr/lib 中也没有任何 32 位库。ARM 本身提供支持 Thumb 的 GNU 编译器，其他来源也是如此。使用 Thumb 作为编译器目标将节省内存，但可能会牺牲性能。对于非 CPU 密集型的常驻守护进程来说，这可能是一个合理的选择。

树莓派上的 Oracle Linux 中一个明显的不足是缺少 WiFi 设备。内核 dmesg 提供了问题的线索


brcmfmac: brcmf_fw_map_chip_to_name: using
        brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221)
         ↪rev 0x000006
usbcore: registered new interface driver brcmfmac
brcmfmac mmc1:0001:1: Direct firmware load for
                         brcm/brcmfmac43455-sdio.bin failed
                          ↪with error -2

您可以在此链接找到缺少固件的一个来源，尽管您也可以在 Raspbian 中找到它。安装固件将导致出现 wlan0 设备，但我配置它的所有尝试都失败了。尽管有 brcmfmac 内核模块，但在当前版本中它似乎不起作用


[root@rpi3 ~]# cd /usr/lib/firmware/brcm/
[root@rpi3 ~]# ll brcmfmac43455*

-rw-r--r-- 1 root root 600487 Jan 14 19:33
 ↪brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root  14036 Jan 14 19:49
 ↪brcmfmac43455-sdio.clm_blob
-rw-r--r-- 1 root root   2054 Jan 14 19:41
 ↪brcmfmac43455-sdio.txt

树莓派上的 WiFi 和蓝牙设备似乎通过 SD 卡的 SDIO 接口工作。一旦这些文件到位，请重新启动，WiFi 驱动程序应会出现在 dmesg 中。请注意，这将使用少量额外的内存


mmc1: new high speed SDIO card at address 0001
brcmfmac: brcmf_fw_map_chip_to_name: using
        brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221)
         ↪rev 0x000006
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
      Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY)
       ↪FWID 01-4fbe0b04
Bluetooth: Generic Bluetooth SDIO driver ver 0.1

在 Oracle 关于 AArch64 版本的文档中，完全没有提及树莓派上的 WiFi 硬件，Oracle 声称这是一个疏忽。这在 CentOS 中似乎也是一个问题，至少在 CentOS 中讨论过一些篇幅。

代码密度

由于 Pi 上包含的 1GB 内存受到限制，您应该了解 AArch64 带来的性能损失。

下面是一个脚本，我用它来调整在原始树莓派上运行的 Raspbian Linux 中的所有 ELF 二进制文件的大小，并将其存储在文件 a32.txt 中


for x in /bin/*
do [ -f "$x" ] &&
   case "$(file "$x")" in
        *ELF*) stat -c %n\ %s "$x";;
   esac
done > a32.txt

将此文件移动到在树莓派 Model 3 B+ 上运行的 Oracle Linux 后，我运行以下命令来查找大小差异


while read p s
do [ -f "$p" ] &&
   case "$(file "$p")" in
        *ELF*) echo $p $s $(stat -c %s "$p");;
   esac
done < a32.txt | awk '
    {a+=$2; b+=$3; print $1,$2,$3,$3/$2}
END {print a,b,b/a}' > a64.txt

对于这 66 个文件的少量样本，我发现了表 1 中显示的结果。

表 1. 66 个文件的大小差异结果

程序	Raspbian	OL7.6	% 增加
/bin/bash	912712	971728	1.06466
/bin/cat	30560	70408	2.30393
/bin/chgrp	51084	70944	1.38877
/bin/chmod	46956	70840	1.50865
/bin/chown	51092	71000	1.38965
/bin/cp	104592	204296	1.95327
/bin/cpio	118460	141752	1.19662
/bin/date	83868	70368	0.839033
/bin/dd	63424	136456	2.15149
/bin/df	67876	137848	2.03088
/bin/dir	108804	138240	1.27054
/bin/dmesg	59484	78296	1.31625
/bin/echo	26404	69904	2.64748
/bin/false	22304	69880	3.13307
/bin/findmnt	52144	71992	1.38064
/bin/grep	173656	204048	1.17501
/bin/gzip	80476	137400	1.70734
/bin/hostname	13964	69048	4.94471
/bin/journalctl	63204	538448	8.51921
/bin/kill	22020	70432	3.19855
/bin/kmod	128560	203960	1.5865
/bin/less	151392	219472	1.44969
/bin/lessecho	9688	68752	7.09661
/bin/lesskey	14460	70320	4.86307
/bin/ln	46976	70848	1.50817
/bin/login	39112	70032	1.79055
/bin/loginctl	42732	538280	12.5966
/bin/ls	108804	138240	1.27054
/bin/lsblk	67756	138336	2.04168
/bin/mkdir	63472	137080	2.15969
/bin/mknod	55248	71272	1.29004
/bin/mktemp	34668	70288	2.02746
/bin/more	34708	69824	2.01176
/bin/mount	34872	68840	1.97408
/bin/mountpoint	9896	68944	6.96686
/bin/mv	100504	138480	1.37786
/bin/netstat	106676	211912	1.9865
/bin/ping	55720	70208	1.26001
/bin/ps	83624	137000	1.63829
/bin/pwd	26452	70056	2.64842
/bin/readlink	34628	70448	2.03442
/bin/rm	51076	71056	1.39118
/bin/rmdir	34628	70072	2.02356
/bin/sed	84100	71904	0.854982
/bin/sleep	26416	69984	2.6493
/bin/stty	59240	70240	1.18569
/bin/su	31016	69008	2.22492
/bin/sync	26424	69912	2.64578
/bin/systemctl	161680	738032	4.56477
/bin/systemd-ask-password	9948	70000	7.03659
/bin/systemd-escape	9936	69816	7.02657
/bin/systemd-hwdb	67520	136520	2.02192
/bin/systemd-inhibit	14040	337728	24.0547
/bin/systemd-machine-id-setup	18128	69912	3.85658
/bin/systemd-notify	9936	69728	7.01771
/bin/systemd-tmpfiles	50988	202912	3.9796
/bin/systemd-tty-ask-password-agent	26324	135920	5.16335
/bin/tailf	22288	69488	3.11773
/bin/tar	327644	350288	1.06911
/bin/touch	71584	70640	0.986813
/bin/true	22304	69880	3.13307
/bin/udevadm	395336	469248	1.18696
/bin/umount	22436	68856	3.069
/bin/uname	26416	69928	2.64718
/bin/vdir	108804	138240	1.27054
/bin/wdctl	26408	70256	2.66041
	5107652	9795488	1.91781

这些程序在 Oracle Linux 中占用的空间几乎是在 Raspbian 中的两倍。这在一定程度上解释了 CentOS 决定继续使用 AArch32 和较小的 32 位二进制文件的原因。Oracle 对 AArch64 的追求可能是由于它支持或将来可能支持的类似平台。

如果 Oracle 选择提供 Thumb2 开发环境，就像它支持 32 位 x86 一样，那么 Oracle 可以生成比 Raspbian 中更小的二进制文件，同时仍然运行 64 位内核，但会牺牲一些性能。这假设所有目标平台都支持 Thumb2；但从所有迹象来看，富士通 A64FX 并不支持。

检查常用服务器守护程序、系统库并提取所有这些程序中的 text/data/bss 段大小可能很有用，以便更详细地了解此处付出的 AArch64 性能损失。鼓励拥有大型 ARM 部署的用户这样做。

结论

很高兴看到一个新的 Linux 发行版削减了传统支持，这在 Intel/AMD64 环境中是永远无法容忍的。维护过去数十年的系统存在巨大的复杂性和惯性。

尽管如此，文档中关于（被忽视的 WiFi）硬件支持以及传统 Thumb 和 AArch32 指令集问题的相对沉默仍然令人不安。操作系统供应商应明确说明其产品在目标硬件上可以做什么和不能做什么。虽然 Oracle AArch64 Linux 存在缺乏这种明确性的问题，但必须承认这是一个预生产版本，并且所需的明确性和受支持的服务器级 AArch64 目标平台可能还不存在。重申一下，一个可能的硬件目标是富士通 A64FX，设计人员声称它是世界上最快的处理器。亚马逊最近也开始在其 EC2 云中使用其 Graviton 处理器运行 ARM 工作负载，但 Graviton 预计不会超过富士通 A64FX 的性能，而且亚马逊和 Oracle 之间的关系并不融洽。Oracle 也可能正在开发自己的 AArch64，专门针对 Oracle 的数据库进行调整。Oracle 之前一直以这种身份维护 SPARC，并且继续凭借它在 TPC 基准测试中占据主导地位；该公司也可能决定用自己的 ARM 处理器来做这件事。

关于 Oracle 数据库，没有任何关于它的讨论或提及也引起了对该平台寿命的极大担忧。

无论如何，Oracle AArch64 Linux 可能会被许多追求低功耗、大内存应用程序的人使用。树莓派可能能够为那些更大的系统提供开发环境。看到 ARM 进入企业领域令人鼓舞，并且摆脱了传统计算环境，没有英特尔的所有问题 (Meltdown)、丑闻 (ME/PSP) 和固件问题，这真是令人耳目一新。

资源