QEMU 构建
qemu 的 configure 并没有使用 Autotools 那一套，而是手写的 configure shell 脚本，但是命令行选项模拟了 Autotools 的实现，如显式启用、禁用特性：
--enable-foo, --disable-foo
configure 原理特性的控制当前分两部分，一部分是 configure 脚本实现，一部分是 meson 构建工具实现，但最终会统一至 meson，如对 rbd 特性的修改：
rbd: convert to mesonhttps://github.com/qemu/qemu/commit/fabd1e93d93ef90ddf8574a42aee406314cc47c4
configure 脚本实现的开关yes/no/""/default_feature，如：libpmem="$default_feature"
default_feature 默认为 ""
--without-default-features 选项将设置 default_feature 为 no
123456 ...
cargo package 时间戳错误
问题现象构建 proxmox-backup deb 包时总是出现如下的 lintian 错误：
12E: proxmox-backup-server: package-contains-ancient-file etc/apt/sources.list.d/pbs-enterprise.list 1973-11-29E: proxmox-backup-server: package-contains-ancient-file lib/systemd/system/proxmox-backup-daily-update.timer 1973-11-29
问题分析解压 deb 之后确认问题真实存在：
123456789101112131415161718$ stat etc/apt/sources.list.d/pbs-enterprise.list File: etc/apt/sources.list.d/pbs-enterprise.list Size: 70 Blocks: 8 IO Block: 4096 regular fil ...
kmod-ceph
作为一个大规模使用的开源分布式统一存储系统，Ceph 支持多种形式的客户端访问，其中 Linux 内核原生支持访问 CephFS 文件存储（kcephfs）和 RBD 块存储（krbd）。
Ceph 内核客户端Ceph 的内核客户端模块有三个：drivers/block/rbd.ko, fs/ceph/ceph.ko, net/ceph/libceph.ko。显然 rbd.ko 对应 RBD 客户端，ceph.ko 对应 CephFS 客户端，而 libceph.ko 起类似于用户态客户端中 librados 的角色，是 rbd.ko 和 ceph.ko 的依赖模块。
虽然从 RHEL 7 开始 RedHat 的工程师在持续的 backport 内核客户端补丁到 RHEL 商用内核上来，但显然 Linux 内核客户端的支持本来一直以来都是滞后于服务端的发展，然后 backport 的补丁 bugfix 多于 feature，而且由于外场部署的商用内核升级又明显要滞后 RHEL 的内核，因此不可避免的，如果需要在商用产品上继续使用 in-tree 内核态客户端，会存在诸多限制。
kmod ...
rpm spec autopatch 实现
问题rpm spec 中的 Patch（或者 Source）能否指定目录前缀？
如能否以如下的方式指定文件路径：
12Source0: a/b/cPatch0: a/b/c
代码分析%autopatch 宏实现如下，通过 lua 内置函数 ipairs 遍历 patches table 遍历，得到每个通过 Patch 定义的补丁路径，并最终应用补丁：
123456789101112131415161718192021222324252627282930## /lib/rpm/macros# Single patch application%apply_patch(qp:m:)\%{lua:\local file = rpm.expand("%{1}")\local num = rpm.expand("%{2}")\if posix.access(file, "r") then\ local options = rpm.expand("%{-q ...
搭建基于 SQLite 的 joplin server
服务端配置构建 joplin server12345$ cd /home/runsisi/runsisi.com/$ git clone https://github.com/laurent22/joplin.git$ cd joplin/packages/server/$ npm install$ npm run tsc
创建 joplin 用户创建用户：
1$ sudo useradd -M joplin -s /usr/sbin/nologin
并且为 joplin 用户添加 joplin/packages/server/ 目录访问权限：
12$ cd ..$ setfacl -m u:joplin:rwx server/
创建 systemd 服务123$ sudo vi /etc/default/joplinAPP_BASE_URL=https://joplin.runsisi.comAPP_PORT=8080
123456789101112131415161718$ sudo vi /lib/systemd/system/joplin.service[Unit]De ...
Ceph 受墙上时间调整影响分析
我们知道，Ceph 集群在部署时要求各节点通过 NTP 统一各自的系统时间，而且 MON 还会检测 MON 集群各节点间的时间差异，当超过一定阈值（mon_clock_drift_allowed）时产生相应的告警，但实际上在 Ceph 集群对集群各节点（甚至客户端节点）的时间有非常严格的要求（主要包括保持各节点时间同步、禁止时间跳变），本文将对 Ceph 涉及的时间各方面进行一个较详细的分析解读。
需要注意的是，本文引用的代码都基于 Ceph Luminous 版本，不同 Luminous 小版本之间代码可能有细微的差异，但不影响这里的分析。新版本 Ceph 在时间处理上有一些改变，但显然还远未做到对时间不敏感。
此外，不仅仅是 Ceph 自身代码需要处理系统时间调整的问题，本文涉及的墙上时间/单调时间选择、条件变量超时等待、定时器在 Ceph 依赖的其它组件同样会遇到，比如为了规避系统时间调整的问题，dmClock 的代码就有一处将 CLOCK_REALTIME 时间改成 CLOCK_MONOTONIC 的改动，当然这不是本文的重点。
C/C++ 时间虽然 Ceph 当前已全面支持 ...
搭建基于 SQLite 的 Typecho 站点
博客系统从 Hugo 迁移到 Typecho 了，这里简单记录一下安装配置过程。
环境为 Ubuntu 20.04，总的来说挺顺利的。
安装首先安装 PHP 8.0、SQLite 扩展，以及一些和 handsome 主题相关的扩展。
123$ sudo add-apt-repository ppa:ondrej/php$ sudo apt install php8.0-fpm php8.0-sqlite3 php8.0-mbstring php8.0-curl$ systemctl status php8.0-fpm
配置 PHP1234$ grep ^listen /etc/php/8.0/fpm/pool.d/www.conflisten = /run/php/php8.0-fpm.socklisten.owner = www-datalisten.group = www-data
配置 Nginx1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950 ...
从 hugo 迁移至 typecho
博客已经从 Hugo 切换至 Typecho !
从 cppblog 到 Pelican 到 Gatsby 到 Hugo 再到 Typecho，一直在折腾 :)
Gatsby
Hugo
Typecho
vstart 环境使用 RDMA
showgids.sh 脚本12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182#!/bin/bashblack='\E[30;50m'red='\E[31;50m'green='\E[32;50m'yellow='\E[33;50m'blue='\E[34;50m'magenta='\E[35;50m'cyan='\E[36;50m'white='\E[37;50m'bold='\033[1m'gid_count=0# cecho (color echo) prints text in color.# first parameter should be ...
rdma-core 构建与使用
在编写 rdma 代码时，有时候需要使用 gdb 进行调试，或者需要修改 rdma-core 自身的代码进行代码分析，或者需要使用新版本进行测试，在这些场景下通常有必要在本地对 rdma-core 进行构建。
由于这里我们只考虑在本地的编译、调试，因此，不会涉及 rpm 包之类的构建，这些会在独立的文档中进行描述。
构建rdma-core 的构建体系使用的是 CMake，因此构建起来非常的容易，和其它的 CMake 工程构建没有什么差异：
123456$ git clone https://github.com/linux-rdma/rdma-core.git$ cd rdma-core/$ mkdir build$ cd build/$ cmake -DIN_PLACE=1 ..$ make
注意 cmake 命令行中的 IN_PLACE 宏定义，这样本地构建的命令行程序才会使用 build/etc/ 目录下的配置文件（否则需要定义 CMAKE_INSTALL_PREFIX 为 /usr，这样命令行程序会加载系统目录下配置），默认构建（既不定义 IN_PLACE，也不定义 CMAK ...