# 2021-50: 奇妙的探险

## 新玩具

这周花了大概两天的时间折腾自己新到手的玩具：联想拯救者刃 7000P。加入 Datafuselabs 可以选择配置一台自己的电脑，考虑到我大多数时候都在家办公，我选择了配置一台主机：R9-5950X + 64G 内存 + 1TB SSD 可以让我畅快的 `cargo build` 而不用担心性能跟不上，RX6900XT 还能让我在工作之余玩一些 3A 大作（嘿嘿）。配好主机之后公司的同学还主动给我加配了一个 DELL U2720QM 27寸 4K 显示器，搭配上我前不久入手的 ThinkPad TrackPoint Keyboard II，这下我的主机开发机一下子就跟上了时代。

电脑到手上电，进入自带的 Windows 简单测试一下没问题之后就掏出了我的 ArchISO 开始安装 Archlinux，结果发现内核无法正常驱动无线网卡：lspci 能看到，可是 ip link 中却完全看不到设备。

```shell
04:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device 8852
```

于是我被迫将手机当作 USB 网卡完成了系统 Bootstrap 的工作。在 AUR 上搜索一下之后发现我可能需要安装 `rtw89-dkms-git`（虽然维护者指出从 Linux 5.16 开始已经内置 rtw89），接下来就是一套 `git clone & makpkg -si` 的操作，然后发现无线网卡能用了！陆陆续续完成各项配置的导入工作之后（感谢之前一直在维护的 dotfiles），发现这个网卡定时出现断流的问题，非常影响使用。在驱动的上游项目 [rtw89](https://github.com/lwfinger/rtw89) 一番搜索之后发现了很多人都汇报了类似的问题，在 `dmesg` 也能看到不少驱动相关的报错，好在维护者已经提供了解决方案：修改 `rtw89` 驱动的配置，禁用 `aspm_l1` 支持，具体的来说是增加 `/etc/modprobe.d/50-rtw89.conf` 文件，并写入如下内容，

```text
options rtw89pci disable_aspm_l1=y
```

看起来问题的根源还是联想的 buggy BIOS 没有正确的实现 PCI Specs，导致网卡的 [ASPM](https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/6/html/power_management_guide/aspm) (Active State Power Management，主动状态电源管理) 在切换状态的时候工作不正常，这里采用的 workaround 就是彻底关闭 L1 状态的切换，缺点是耗电会增加。不过我的使用场景并不是移动设备，所以完全可以接受。

搞定了网卡的问题之后，接下来的使用特别畅快：快，做什么都快。装包快，编译快，打开快。我慷慨地允许 Jetbrains IDEA 使用 16G 内存，我戒掉了手动内存管理的习惯，我打开 htop 只是为了看看 32 个核心沸腾的场面而不是为了看自己还有多少可用内存。

现在就是特别后悔，当年早该攒钱升级设备的，受了太多委屈。

## 新方向

这一周完成了一些后续的扫尾工作，现在 Databend 的 CI 已经非常顺滑了：

![](https://xuanwo.io/reports/2021-50/databend-ci.png)

现在的 CI 能够做到如下的事情：

- 前置的检查不通过就不会触发后续的任务
- 后续的测试能够使用前面构建的产物，不需要再次构建
- 自动取消同一分支上的构建，避免排队堆积

相比于改进之前：

- 每个 PR 的构建时间从 40+ 分钟下降到了 20+ 分钟
- 每个主干 Commit 的构建时间从 2 小时下降到了 1 小时
- 完整且正确地实现了 aarch 平台上的构建与测试

总得来说成果还是让人满意。当然效率的改进是永无止境的，社区还有些新的想法：

- [Re-organise our building systems](https://github.com/datafuselabs/databend/discussions/3419)： 项目之前为了降低开发者门槛，使用了大量脚本来完成工作，为我们的构建系统增加了不少复杂度。这个提议旨在重新组织/设计我们的构建系统，降低维护和理解的复杂度
- [[Test/Integration] implement generic test framework for integration test](https://github.com/datafuselabs/databend/issues/2647)：测试是重中之中，之前项目用 Python 写了一些简单的测试脚本，后面需要实现一个统一的测试框架来执行整个系统的集成测试

这周除了效率工程上的问题之外，我也开始给 databend 主干做一些贡献：

- [common/arrow: Fix build on newer arrow2 commits](https://github.com/datafuselabs/databend/pull/3500)
- [functions: Add lower support](https://github.com/datafuselabs/databend/pull/3521)
- [functions/lower: Reduce extra memcopy](https://github.com/datafuselabs/databend/pull/3525)

现在还是以学习为主，接下來会结合着 [CMU 15-445](https://15445.courses.cs.cmu.edu/fall2021/) 来看看 Databend 的对应模块并分别做一些贡献。就目前来看，我对存储和执行模块是最感兴趣的，databend 中跟底层存储最接近的模块叫做 DAL (Data Access Layer)，这是一个存储的抽象，接下來需要实现不同存储的对接（这是我的老本行了）。在 Databend v0.7 版本中，我期望做到如下事情：

- [dal: Refactor to make it easier for contributors to add new storage type](https://github.com/datafuselabs/databend/issues/3436)
- [dal: Add more underlying storage support](https://github.com/datafuselabs/databend/issues/3434)
- [dal: Add integration tests target on production services](https://github.com/datafuselabs/databend/issues/3435)

未来如果能够成功从 Databend 中孵化出来，我可能就从新的方向再次圆了 BeyondStorage 未曾实现的梦想吧（
