D0

我的行程在 https://github.com/CalvinNeo/CalvinSchedule 中。

D1 初一

因为我对象年三十值班，所以我们是定了初一下午的飞机飞呼和浩特。为什么去呼和浩特是因为去长春的飞机票买晚了，所以在选择从大连出发玩东北，还是从呼和浩特出发玩呼和浩特和大同之间的权衡。

事实证明，呼和浩特是一个挺好的地方，首先它去大同比太原还要方便，其次，它的机场到高铁站很方便，所以我们直接定一个高铁站旁边的酒店就非常舒服了。不过据说呼和浩特的新机场要启用了，因此后面它就没太原爽了。

因为我们值机比较靠前，所以下飞机是比较快的，然后就直往地铁站跑，赶上了倒数第二班地铁。事实证明坐地铁还是对的，因为后面我们点了个鼎鼎眼镜烧烤，发现等了好久都没有骑手接单，最后还是加钱人家才送的。

D2 初二

今天起来还是很感冒，还是流鼻涕。

早上 8 点，我们的小团才接我。这也是因为我们住在呼市最东边的缘故，所以不用起那么早。车上除了我全是女的，所以我就坐在副驾驶了。这个副驾驶的头枕非常靠后，所以我睡起来很不方便。

第一站是辉腾草原上面的马场。这个马场除了骑马和卡丁车（实际上没人玩）啥都没有，所以尽管我们没有定骑马的套餐，所以逼到最后还是只能骑马。那边报价 140，而淘宝只要加 120，所以我们用淘宝价还价骑了马，然后又加了 120 骑了快马。
大概流程就是先上一匹小马，然后几匹马一起被牵着走到跑马场。到那边老板就问要不要骑快马，如果骑，就换到大马身上。然后老板就会同时拉着你的缰绳和自己的缰绳把马跑起来，嘴上还嘚嘚嘚嘚的。一开始马是小跑，这个时候你得用腿用力夹住马的肚子。不过后面马就会撒开来快跑了，这个时候，就是颠屁股了，感觉整个人都要散架，必须要拉着马鞍才会稳一点，然后就跑完了。

总的来讲感觉价格偏贵。体验上的话，快马还是可以的，不过时间也很短。当然，再长一点，我呛风也受不了了。然后这地方的旱厕也是堪称一绝，里面的屎冻成了棍子，我也是第一次见。导游说你就路边上尿吧，我寻思这么大的风，不吹到身上么。

然后就是去吃饭，开车到了右翼中旗县城里面，就开了那么几家店。我们选了一家，我对象点了个羊杂，点了个驼饼。我吃了下，感觉羊杂还挺香的，驼饼感觉就是普通的肉饼吧，然后查了下，说是骆驼肉。

吃完饭，就去火山了，这个也是要开一大段路的。那一块其实有很多火山，有的火山形状像草帽山，我把它叫土帽山。不过我们实际去逛的那个叫南炼丹炉，是一个平顶的火山。相比我们在冰岛看到的，这个火山确实有点火山的感觉。

从火山回来，就是长达三个小时的回程了。我们让司机帮我们送到宽巷子，这样就可以直接吃东西了。下车就能看到杨老大焙子店，结果没开门。旁边的星月排满了队，所以我们就去清和园了。这边买芝士奶饼好多都是几十个买的，我们只买了两个感觉很亏。然后我们就去珠萨拉买了几个酸奶糕，是冰着的，感觉挺好吃。

吃完就准备打车去泽成冰煮羊了，这个店在附近有两家。我决定去万象城那一家，因为那边等的时候至少可以逛一逛。事实上感觉也是对的，因为那天晚上我感冒贼难受，加上又很干，嗓子不舒服。

D3 初三

今天需要早起去大同。因为我们在火车站旁边住，所以提前一个小时起床绰绰有余了。内蒙古的火车会说什么内蒙古好羊肉，内蒙古羊肉好，非常洗脑。反正一路上也是比较困，睡睡醒醒的。
从一路上看，内蒙古和山西确实不太一样，首先，内蒙古真的有很多风车。然后，内蒙古感觉是草原的感觉，是有黄草的，但山西的话会更有黄土高原的感觉。

下了大同站，想要拉屎。我对象不在车上拉，结果下了车就要排队。其实始发站的火车，我一般是喜欢在火车上拉屎的，因为一般都很干净。拉完屎还有五分钟，就跑到直通车那里，准备去云冈石窟。上了车，开个大概有一个多小时才到，真的是非常非常堵了。

云冈石窟人非常多，主要体现在：首先，它景区检票口开了好几个，但居然都要排队。其次，是它的讲解也要排队，我们想想还是旅途随身听算了。反正进去之后，就绕了一圈，看了一下它的一个寺庙的前中后殿，然后过了桥，就是石窟的主体。

因为我之前在车上已经预习过了，所以我大概知道这些石窟大概分为几个系列，然后哪些是比较精华的。反正一开始进去的第一窟和第二窟都是比较惨烈的，因为它们的开口很小，所以基本人只能站在石阶上往里面伸着头看，我似乎就看到几个石柱子，感觉没啥意思。

第五窟和第六窟是一起的，实际上我们排最长的也是第六窟，因为第五窟当时已经维修了。保安说要排一个多小时，但实际排了四十几分钟就进去了。这个窟实际上是有前窟和后窟的，云冈石窟大部分也都是这个式样。并且相比于莫高窟或者龙门石窟，云冈石窟的颜色没怎么掉，所以看起来更鲜艳，据说这个可能是因为之前有人补过颜色吧。

琥珀知道我们到了大同，就想跟我们面面基。不过他显然对大同的人流没有预期，搞了半天说要吃紫泥，结果我们去古城紫泥拿了个号，发现要等 290+ 桌。不过我们倒是在古城的凯鸽也排了个号，只有 29。不过考虑到它一直不叫号，并且古城也没啥可以逛的（人特别多），所以我们就准备出去找点东西吃。经过一系列的电话咨询，我们发现紫泥在南环路的一家店还是可以取号的，所以就骑自行车过去。另外，我们一进古城就发现东门排着队，应该是上城墙准备去看花灯的，所以我们也果断不去看灯展了。

骑车过去的路也是比较奇葩，主要是出了古城城门需要往右拐，结果交警让我们走上面走，结果骑着骑着就骑到了永泰门广场上了。这个广场是被拦着的，自行车没法进，我们也下不去。结果我们只能闯过一片烂泥地强行进去，然后又在前面的栅栏的地方，把自行车搬了出去。骑到紫泥那里，是个直梯，上去之后果然全是人，反正是取了个号，然后打算先去找点东西垫垫肚子。先骑车去旁边的和笙财，点了个沙棘冰淇淋，这个冰淇淋是真好吃。然后发现旁边就是老柴削面的总店，但是我对象还是想吃喜晋道，所以就骑车去旁边的喜晋道，中途路过大同一中，感觉这个学校真的是富丽堂皇啊。进去喜晋道，他家是一个非常大的门面，装修非常漂亮，但是一进去，就说没位置了，并且都不发号了。于是就灰溜溜排老柴削面。再过去，就发现老柴削面外面都全是人了。

D4 初四

今天继续是早起的一天，我们需要去恒山景区。从酒店到南站有一定距离，还是扫了个车骑了过去。然后，发现百度导航真的是糟糕，直通车明明是车站的另一端，它给标错了。总之赶到了直通车那，说恒山的车堵在高架上，可能要晚点。然后我就去上了个厕所，果然是上厕所定律了，上到一半，车就来了，结果我赶快跑了回去。在车上迷迷糊糊睡到恒山，到了那个游客中心附近又开始堵车了。总之到了下面，就要坐摆渡车，我也看到了之前在小红书上看到的排队标志，所幸今天的人没有昨天多，不过悬空寺方向还是挺长的，所以我们决定先去爬恒山了。

去恒山的车会经过悬空寺，在经过一个隧道之前，能看到悬空寺，并且这是一个很好的从上往下看的机位，建议不要错过，因为返程的时候，需要倒着头向后来看，不是很方便。

到了恒山脚下，我决定还是坐摆渡车上山，爬上去，然后索道下来。中间我对象买了个帽子，然后就又去排上山的队。今天可能景区被骂优化过了，所以我们在排摆渡车之前就检票了，没有等很久。一辆车走了之后，等了一会，然后突然开过来五辆车，都并排停了。我们上了第一辆车的最后一排，我对象不太乐意，因为她有点晕车。

上了摆渡车，很快就到真武庙了，从这里就往上爬。我带了个 insta360 的相机，可以看到，全程都很简单，我觉得都没有南京紫金山难爬。中间有个庙，爬上去的石阶比较陡，感觉应该是最困难的部分了，但其实也就那样。然后从庙出来，就是冲顶阶段了，过了一个叫氵麦极门的地方之后，就看到小红书上堵人的地方，我们不出意料也开始堵了。感觉就是从这里开始，台阶变得高了点，所以有的人就要歇歇了，加上石阶又变窄了，所以交通就阻塞了，好在这一段不是很长，很快就到了一个亭子那。那是一个三岔路，往左是索道下山方向，往右是登顶方向。我们登顶，好在那里石阶就宽很多了，基本都可以跑起来，所以跑了大概十几分钟，我也登顶了。总共算上等的时间是六十几分钟吧。总的来说，恒山其实没啥意思，主打一个五岳打卡。然后确实很多人都在峰顶的那个地理标识那边排队拍照，说那边一个人只有 20s 的拍照时间。

下到缆车的地方，看到人也不是很多，就打算坐缆车，结果下来之后发现别有洞天，还是排了不少的。不过其实是可以忍受的，实际上也就等了不到二十分钟。中间前面的京爷因为不知道什么事情吵起来了，然后又打起来了，然后又吵起来了，反正我们就翻栏杆排到了他们前面，感觉也是个乐子。下山就直奔摆渡车站，去古城的在排队，但是去悬空寺的不需要排队，我们就直接上了。

D5 初五

今天算是比较奇妙的一天。首先，昨天晚上睡觉前跟我对象讨论了，说今天早上去应县木塔吧。然后晚一点我就想把直通车的票买了，结果一看，9.30 的票只有一张了。因为木塔下午人多，并且，从木塔回古城更顺，所以我们又只能买早上的，就很尴尬。我还不信邪，又刷了几遍，中间还错买了去恒山的，总归坐直通车是不行了。灵机一动，决定去搜下有没有其他的巴士，结果 902 好像要两个多小时，不过中途发现，应县是有高铁站的，并且高铁站也是有巴士去木塔景区的，所以我就决定买火车票了。结果 12306 晚上关门，没法买票，于是我只能定了早上的闹钟。早上起来，发现买票是需要在系统里面排队的，我等了几十秒发现还没刷出来，就又小眯了会。几分钟又醒了，发现刷了两个不挨着的座位，果断付了款，结果再一开，火车票就卖空了。

结果上了高铁，发现这趟高铁也不算特别挤啊，不知道在那里票都卖光了。不过我们一站就到了应县西站，然后门口就是蓝色巴士，五块钱就到木塔了。然后发现这个巴士似乎也接路上的村民，并且送到木塔之后，也会继续往前开的。

因为我们是高铁来的，所以应该比大部队要早，到的时候，木塔没啥人，跟之前小红书上看到的完全不一样。我们进去之后，逛了两次一层，分别是从左边和右边走的，所以对里面的雕塑和浮雕看的都比较清楚。实际上我们去的时候，木塔二层上是有工作人员在跑动的，只是不知道他们在做什么。站在木塔下面，如果角度不对，其实是不太看的出来木塔已经歪了的。但是确实能看到它的暗层，也确实能看到之前被敲掉的泥墙被换成的窗户，也理解那边的本地人为什么要把泥墙砸掉。

准备离开木塔的时候，风突然大了起来，并且沙子也多了。身边的游客在感叹，这地方还真的是太干旱了，风沙多，结果后来才知道，这是多年没见过的沙尘暴，是从蒙古国吹过来的。总而言之，离开的时候，回望木塔已经是灰黄笼罩的一片了。

前面那条街还在表演，看了会，就往回走，结果那妖风是越来越大了。走到南门出来的哪个巷子中，推开一个铁门，然后就走到一片很很乡下的地方。前面几个人躲着不肯走，我们过去一看，好家伙，前面黄沙都飞起来了。

在排队的时候，我要上厕所，结果用百度找了几个厕所，一个都没有用，还是问的别人。后面立即下了高德，发现高德是准的。上完厕所，就直接去晋喜道了，当时已经快排到我们了。我们点了个肉末的面，一个番茄面，几个小菜，鸡爪，串和沙棘汁。小菜方面，我觉得山西的醋确实香，配上大蒜末，所以那个蒜泥肘花就很好吃了。鸡爪感觉就是茶叶蛋的味道。凉拌黄花算是山西特色了，和其他店里没啥区别。肉末面和昨天吃的老柴总店也是比较类似的，不过没有那么咸，更有点汤面的感觉。番茄面比之前在全季早饭吃的稍微好点，主要它不太是那种面是面，浇头是浇头的感觉，相对来说入味点，番茄泥也弄得比较干净。

因为这两天走的屁股都肿了，所以吃完走到东门打了个车，就直接回去了。

D6 初六

今天在大同逛一下博物馆，就可以回呼和浩特了。早上起来退房，打车去博物馆。我们没有抢到预约，所以只能买特展的票。一开始我以为可以在门口给大爷看完就退了，结果发现这只是一个预检票，后面还有一道需要刷二维码的闸机呢。

进去之后，逛了一会一楼，上了个厕所，出来然后一个女的就问我们要不要拼团讲解，说是 100 块钱，看我们可能要急着走，就说 80 块钱算了，结果我们就定了。中间想先去看一半穆夏的特展，结果人家说只能进去一次，所以就放弃了，又下来。不过好在那讲解员拉客能力比较强，很快就齐活了，她先照着大厅里面的那个壁画讲了一遍，后面我们才知道，这个壁画并不被公开展示。然后我们就又从恐龙那边开始逛了。不过不同的讲解员的路线略有区别，所以我们这次就没有讲那个编织壶。我问了下，那个恐龙为什么那么完整，讲解员说这个叫什么天镇恐龙，当时挖出来也不是完整的，说是考古学家拼的。反正没懂我意思，因为有些恐龙是会缺几个骨头的，但是这几个恐龙是完整的。

二楼是比较精华的部分，即北魏展厅，因为大同直接是北魏的都城。其实它有两个展厅，讲解员只带我们逛了第一个。第一个中又分为两个主题，第一个主题是一个墓葬里面的发掘物，包含了漆画屏风以及它的附属，包括挂它的架子、柱子、石墩子都展示出来了。然后还有对应的墓志铭，以及一些陪葬的陶俑。第二个主题是丝绸之路，包含一些陶俑、壁画以及玻璃制品。这里的玻璃制品还是很漂亮的，是非常剔透的蓝色。

三楼是辽金和明清展厅，大同是北魏的陪都。然后，看到了一个非常大的鸱吻，说是从某个大殿上拿下来的。说鸱吻是龙和鲸鱼的后代，它长得就很像鲸鱼的尾巴。

讲解团解散之后，就去逛了下穆夏的特展。这个人是画板画的，不过眼睛画的很传神。另外，他也会画油画。

D7 初七

今天早上打车去了大召寺。这个寺是藏传佛教的，我不太懂，感觉没啥意思。有一个乃琼庙，里面都是骷髅头，很吓人。

从大召寺出来，就是塞上老街，我们又去吃了泽成冰煮羊，吃完，就打车去内蒙古博物馆。这个车是真离谱，调个头就花了十几分钟，堵得要死，结果我们等了有 20min 才上车。

我的项目是 https://github.com/CalvinNeo/OpenBoardGame。

D0

作为 Demo 实现了一个掼蛋游戏。

发现问题：

• AI 对规则理解非常不正确，例如缺少对三带二、同花顺炸弹的支持，并且也不能顺子的长度和一手牌数量的上限。
• AI 对空间感不熟悉，一些提示文字和牌重合。

# Jan28 - Jan29

在这 2 天中，我大概用了 45 刀左右的额度。完成了 Cabo、骷髅牌、你画我猜、璀璨宝石四个游戏逻辑和 Bot 的开发。并且，我还支持了断开重连、房间管理等机制。我还优化了 UI 的美观度和便捷度。

AI 会理解错一些点。例如 https://github.com/CalvinNeo/OpenBoardGame/commit/ab26a9c00cd5d9720b39bf3e248b672881cb52ed 这个修复 commit 就展示了 AI 对璀璨宝石最大数量的多次理解问题：

1. 一开始，它根本没有实现这个限制。
2. 后面，它实现为只有超过 10 才不能拿，但是从 9 到 12 这个行为是被它允许的。
3. 最后，才修改对了。

AI 会漏掉一些情况。例如 https://github.com/CalvinNeo/OpenBoardGame/commit/c8e82736975325f0b9300b471524ec86b005129e#diff-794e220aafafcfac193a89abd6fb142d92255d544728f217d64e7a1162c79e28 这个修复 commit 展示了 AI 对用户离开规则的遗漏：

1. 先前，AI 处理了 in game 的情况。此时如果最后一个活人玩家离开游戏，那么这个房间可以被手动清理掉。
2. 但是，它漏掉了 in lobby 的情况。此时房间并没有开始游戏，那么玩家离开房间（比如创建一个新的房间）不会导致该房间出于可以被清理的状态。

经验：

• 让 agent 缩小阅读的范围。例如可以告诉它“这是完全的前端修改，你不需要看后端代码或者其他游戏的代码”，这样它就可以更快解决问题，并且能节省不少额度。这随着项目增大是尤为有效的，因为看 thinking 是可以发现它有倾向去学习其他代码是怎么做的。
• 让 AI 先整理信息，然后再写一个 design 征求意见非常重要。因为 AI 在实现的时候还是偏向于漏点东西的，这也可能是出于对问题的不正确理解。
• 逻辑比较独立的部分，可以让 AI 整理出测试。虽然目前也没看到 AI 会主动修改代码从而 break 掉测试，但这样会更有自信。

Jan 30 - Jan 31

这几天主要实现了出包魔法师、猜狐狸、截码战三个游戏。

Feb 1 - Feb 3

这几天主要实现了角斗士棋、Store&Load、印象花语、AI 画物语四个游戏。主要是由 Gemini 生成游戏说明书，再由 Codex 生成 design。等我 Review 了之后，再实现代码。

角斗士棋和印象花语中都涉及到了拖拽旋转对象的设计。我发现 AI 在适配手机端上的拖拽是相对比较蠢的，需要手动告诉怎么搞。

角斗士棋实现起来很简单，但是其实要打磨的很多：

• 手机版如何精准地把方块放到格子里面就很难困难。因为每个方块的焦点并不是方块的重心。后来加了上下左右移动的键，但是感觉还是很蠢。
• 还有一些奇怪的 bug。

印象花语这个游戏，我对实体版的一些物理效果进行了模拟：

• 因为印章可以印得深浅不一，所以我增加了点按时长来决定透明度的机制。并且我也增加了根据色彩学原理来模拟印章叠加的效果。
• 因为可以倾斜印章，使得只盖一半。所以我增加了一个 Mask 机制，可以去 Clip 印章。这个就好像我在按之前垫了一张废纸，这样章可以只盖一半在画布上。

我觉得这一部分涉及到物理世界的原理的，应该只有人类能意识到并且提出来。

Store&Load 是非常有意思的点，AI 当时给我提供了一个完全不一样的解决方案。例如它执着于解决 Session 的问题，如何处理同名玩家和同名 Room。但是我提出了一个非常简单的做法，就是完全新建一个 Room，然后新玩家可以进去 Claim 老玩家的 Seat。这样做能够减少很多的复杂度。另外，我还发现新创建的房间并不支持 Auto Save 选择了，这个我觉得也是 AI 本身缺乏引申的能力。

AI 画物语的实现是跟其他桌游完全不一样的，因为要涉及生成图。所以我开了 https://github.com/CalvinNeo/aidixitgen 这个 repo。

一开始它是用的 pollinations 做的。然后我发现这个工具经常生成水母，然后问了他，他说是提示词的问题：

为什么这个代码里面的 prompt 这么喜欢生成 jellyfish？
这是一个非常经典且有趣的 AI 生成现象，通常被称为 “模式坍塌” (Mode Collapse) 或 “安全区偏差”。出现大量水母（Jellyfish）、热气球、云朵、漂浮的岛屿，原因主要有三点：
关键词的“刻板印象”： 你的代码里用了 surreal（超现实）、dreamlike（梦幻）、whimsical（异想天开）这些词。 在 AI 的训练数据（Latent Space）里，水母是“梦幻”和“超现实”的超级代表物。它们透明、发光、漂浮，长得就像外星生物，完美符合 AI 对“梦境”的理解。只要你还要“唯美”和“超现实”，AI 就会懒惰地选择水母。
Prompt 缺乏约束： 我们在请求 AI 写创意时，给的指令太宽泛了（”Generate ONE single short… description”）。当指令太宽泛时，AI 会倾向于输出它认为“最稳妥、最符合题意”的高概率词汇。对于 Dixit 风格，水母就是那个“最稳妥”的答案。
风格修饰词的引导： 我们在画图时强制加了 soft colors（柔和色彩）和 floating（虽然没写但 dreamlike 隐含了漂浮感）。这也极大地增加了生成海洋生物或云端生物的概率。

然后，我又发现它生成的东西太容易重复了，例如几乎生成了两个只是风格不同的钟。所以我后面又设计了双主体的方案，结果最后生成的结果是比较理想的了。

后来发现 pollinations 一直 502 了，所以就换 hugglingface 了。

Feb 4 - Feb 6

这几天主要实现了前端美化、Flip 7、德国心脏病、绝妙误解。

主要是由 Gemini 生成游戏说明书以及设计。然后由 Codex 去实现。但是我要求 Codex 在实现前先问我不清楚的项目，而不是自己随便实现一版。事实发现，让 Codex 去问一下自己不知道的，而不代替我做决定，是很重要的。

AI 前端的主要问题：

• UI 直白
  例如用一个列表表示玩家信息。用一个表格表示当前状态。这对玩家而言体感不好，感觉是在上班。
• 没有交互设计
  特别是手机端玩家，操作的时候需要翻来翻去。
• UI 可能存在 Bug
  例如在手机端会发现 Flip 7 的 Game 面板会非常少。

德国心脏病的开发是非常典型的。主要包含几点：

• 得到的开发计划是经典版的 Halli Galli，也就是牌上的水果一定是相同的。这个跟我们玩的不一样，所以后面让它开发了一个 DLC 一样的东西。
• 电脑根本没有给翻拍和按铃的等待时间，所以加上 bot 之后，基本 bot 都是秒按铃，秒翻牌，根本没法玩。即使没有 bot，我们也需要考虑人类的反应时间，以及各个网络的延迟。所以我这里要求加了等待 3s 的按铃时间，以及在点击翻拍后，有一个 1s 的倒计时，方便大家准备看新水果。
• AI 生成的界面依然是列表，这个我让 AI 改成了围成一个圆。

设计

主要概括了 design notes。

需要解决的问题

OSS 方面：

• 现在的 OSS 并不支持原子地移动一系列文件或者一整个目录，或者递归地删除整个目录。而 3FS 的场景（实际上数据库的场景也是这样）涉及要创建一个临时目录，然后对这个目录写入数据，最后将这个目录 move 到最终的位置。
• 3FS 需要广泛使用 symbolic 或者 hard 链接
• 提供一个熟悉的文件接口，我理解这也是 3FS 选择 FUSE 的原因

FUSE 方面：

• 在 Fuse 学习一文中介绍了为什么 FUSE 不支持 Zero Copy。但这也是 FUSE 的缺点之一。
• FUSE 使用一个由 spin lock 保护的多线程共享的队列。3FS 团队的测试显示，400K 4KiB reads per second 的写入负载之后，因为 lock contention 的方法。
• Linux 5.x 上的 fuse 不支持对一个文件的并发写。所以很多需要更大带宽的程序会并发写多个文件。
• 对小的随机非对齐读性能不好，SSD 和 RDMA 网络的带宽没有被利用充分。

但是将 client 实现为一个 VFS 内核模块则能解决上面说的问题，但也更有挑战性。内核的 bug 更难定位和修复。此外，升级的时候需要停掉所有访问这个 fs 的进程，或者重启。

因此，3FS 选择在 FUSE daemon 里面设计一套原生的 client，由它来支持异步的 Zero copy IO。其中，File meta operation 例如 open、close 等还是被 FUSE daemon 处理。但是在 open 的时候会把拿到的 fd 通过 native API 注册。然后就可以通过 native client 去读取数据了。

这个 API 类似于 io_uring，其中关键结构如下：

• Iov
  user process 和 native client 共享的内存
• Ior
  user process 和 native client 通过这个 ring buffer 进行交互。具体方式类似于 io_uring。
  请求会被按照 io_depth 攒批执行，不同的 batch 的执行是并行的。

Metadata 存储

chunk 的分布

文件按 chunk 为粒度，被条带化到多个 replication chain 中。
创建新文件的时候，会根据 stripe size，使用 round robin 的方式，选择一系列的 chain。选出来的这些 chain，会随机分给不同的 chunk 写入。

存储 file atributes

为什么 3FS 的 inode 里的 length 会不准确？因为写路径走的是 CRAQ，而 inode 是在 metadata service 里面的。如果每次写操作完都更新一下 metadata，那么会多一次 metadata RTT，写放大严重，吞吐和延迟都会变差。
但是如果 metadata 迟迟不更新，例如是 100mb，而客户端写到 120mb 就挂了，此时，虽然数据已经通过 CRAQ 持久化到 chunk 存储了，但因为读的时候从 metadata 获得的长度偏小，所以还是在效果上丢失数据。
一种方式是按照 interval 上报更新 metadata，但这就存在不一致窗口。不过先考虑容灾问题，大概有两个方案：

1. 重启之后，从 chunk 存储中恢复数据，并由此更新 metadata。但是从 chunk 扫描数据恢复的代价很大
2. 3FS 的设计是由 client 按照 interval 上报 max writer position，因为 client 上报的 position 一定是已经被 tail 提交了的，所以是安全的。但是如果 client 长期丢失，那么 gap 就得通过第一种方式补齐了。

Chunk 存储

Suppose there are 6 nodes: A, B, C, D, E, F. Each node has 1 SSD. Create 5 storage targets on each SSD: 1, 2, … 5. Then there are 30 targets in total: A1, A2, A3, …, F5. If each chunk has 3 replicas, a chain table is constructed as follows.

这里的 Version 是配置的 Version，节点下线会导致这个增大。

这里的一个 Chain 类似于一个 Raft Group 的概念。但是它也不是像 TiKV 一样跟某一段数据绑定的。一个 Chain 可以被多个 chain table 包含。引入 chain table 的概念，这样对于每一个 file，metadata service 就可以为它选一个 chain table，并根据这个 table 中的 Chain 去 strip 这个 file 的所有 chunk。

Balanced traffic during recovery

如果一个节点 A 故障了，就需要由 Chain 中的其他节点来承担原来 A 的流量。而之前的 Chain table 中，A 节点基本上只和 B、C 玩。

在新的架构中，A 在 Chain 2 里和 B/D 在一起，在 Chain 5 里和 C/F 在一起。

Data replication

一个 Write request 可能是从 client 或者 Chain 的前驱发送出来的。一个节点收到 Write request 后的处理：

• 校验 write request 中的 chain version。
• 通过 RDMA Read 去 pull 写入的数据。如果 client 或者前驱挂掉了，导致拿不到数据。写入就 abort。
• Once the write data is fetched into local memory buffer, a lock for the chunk to be updated is acquired from a lock manager. Concurrent writes to the same chunk are blocked. All writes are serialized at the head target.
• 读取这个 Chunk 的 committed version，对它 apply change，然后将更新后的版本存储为 pending version。版本号是单调连续递增的。
• If the service is the tail, the committed version is atomically replaced by the pending version and an acknowledgment message is sent to the predecessor. Otherwise, the write request is forwarded to the successor. When the committed version is updated, the current chain version is stored as a field in the chunk metadata.
• When an acknowledgment message arrives at a storage service, the service replaces the committed version with the pending version and continues to propagate the message to its predecessor. The local chunk lock is then released.

实现

Chain replication

CRAQ 的最大的特点是：复制链路是固定的，而 Raft 的复制链路因为存在 Quorum 是随机的。因此，对于单个 entry 的复制，Raft 的延迟可能会比 CRAQ好，但是 CRAQ 的延迟和吞吐更稳定，可以被预测。

延迟维度的对比：

1. Raft 最优
   a. 条件：follower 延迟几乎一致、没有网络问题
   b. commit latency 约等于 RTT
2. Raft 最劣
   a. 条件：quorum 中某个 follower 抖动，例如出现了 Write Stall
   b. Throughput 约等于 1 / avg([max(follower latency)]，这里的 avg 因为抖动是不均匀的，因为多数派每次都不一定一样。
3. CRAQ 最优
   a. 条件：链上每个 node 的 hop_latency 相同，管道用满
   b. Throughput ≈ min(hop throughput)，这个很简单，木桶效应嘛。
4. CRAQ 最劣
   a. 条件：链上每个 node 变慢
   b. 存在木桶效应，每个 entry 的提交都被固定变慢。

吞吐维度的对比：

1. Raft 最优
   a. 条件：同延迟。
   b. Throughput ≈ follower replication rate
2. Raft 最劣
   a. 条件：同延迟。
   b. commit latency 等于 max(quorum follower latency)，出现了木桶效应
3. CRAQ 最优
   a. 条件：链上每个 node 的 hop_latency 相同
   b. commit latency 约等于 chain_length * hop_latency。因为 CRAQ 在 Tail 返回确认，所以 3 副本也是两次数据传输，和 Raft 的 1 个 RTT 是接近的。但是链长了，CRAQ 就会变慢。
4. CRAQ 最劣
   a. 条件：存在一个很慢的 node
   b. 同上，但是木桶效应被放大很明显。

CRAQ 的其他特点：

1. 没有 quorum 容错
2. failover 不需要重新选主，但需要重构链。需要根据挂的是哪一个来讨论。

Reference

• https://github.com/deepseek-ai/3FS/blob/main/docs/design_notes.md

常见的表达

避免直接翻译汉语词

少用汉语式的名词化表达，例如“执行 xx 行动”，“处理 xx 过程”。

1
2
3
4
5

the lock is released

===>

the release of the lock is performed

不要自以为是去形容词化。如下，adaptive 的意思是自适应的，和我们实际要指代的“适配代码的行为”是不对应的。

1
2
3
4
5

We need to **adapt** the code to the new behavior. However, this **adaptive** work is not easy.

===>

... However, the adaptation work is not easy.

实词虚化、具体词抽象化

汉语中，很多虚词功能是通过复用实词来的。但是在英语中，如果有对应的虚词，就不要直接翻译汉语中的实词了。

1
2
3
4
5
6

Based on this reason, ...

===>

As a result, ...
For this reason, ...

又例如下面的“带来麻烦”，这里的带来没必要用 bring 这个实词

1
2
3
4
5
6
7

brings lots of trouble to investigate ...

===>

made the issue difficult to investigate ...
// Or
significantly complicated the investigation to ...

又例如下面的“定位到问题”

1
2
3
4
5

The problem is located by ...

===>

The problem was also detected by ...

虚词实化

但是，一些汉语中的虚词，在英语中要实化。例如，“这会导致难以理解的代码”，就是

1
2
3
4
5

It could result in confusing codes.

===>

It could generate confusing codes.

这个原则甚至不限于词，对于任何表达都是这样。This may cause problems，建议直接具体一点说是什么 problems。如

1
2
3

This behavior can cause a deadlock when two tasks hold the mutex across an await point.
// Or
This design is problematic in terms of concurrency safety, because it allows a task to hold a mutex across an await point.

需要调整句子结构

尽量避免使用形式主语 It is 或者 there is 等来拖长表达

1
2
3
4
5

It is hard to inspect the state.

===>

Inspecting the state is difficult.

但注意，非形式主语是可以用 it 的，如下所示，这好过说 “I think” 等

1
2
3

It indicates ...
This implies ...
The result shows ...

从下面的例子中，能感觉到动名词前置的用法，更干练

1
2
3
4
5

I don't think the service itself should persist the updated configuration to the config file. Instead, this should be handled by the operator.

===>

Persisting the updated configuration should be the responsibility of the operator, not the service itself.

语序

副词顺序应该稳定在动词后。

1
2
3
4
5

We must immediately do this.

===>

We must do this immediately.

其他

下面的表达，相比更能体现出不仅不能做之前说的，也不能做现在说的。而 Also 显得更像一个连接。

1
2
3
4
5
6

Also, A can't do sth.

===>

Moreover, A can not do sth either.
We can't ..., nor can we ... .

使用更恰当的单词

使用更精确的词

避免使用

possible -> feasible

使用恰当的搭配

动名词搭配。

辩证具体含义的差别

如：

• be confident of 和 be confident in

宏观写法

先给结论，再给解释（Top-down writing）。

特定场景的表达

偏向数据分析

表达“A使用的内存占A的调用者的比重，相比B使用的内存占B调用者的比重是相近了”，从书面到口语。

1
2
3
4
5
6
7
8

// 这里的 footprint 更专业术语一点。
A’s memory footprint relative to its callers is similar to B’s.

A and B exhibit similar memory-to-caller ratios.

The proportion of memory used by A relative to its callers is similar to that of B.

A and B have similar memory usage ratios with respect to their callers.

• 西安商业化太浓重了，例如大唐不夜城、城墙上骑车等。当然这也不是坏事，但如果玩的多了，就会觉得商业化严重的景点如同预制菜一样，不能说不好吃，但感觉容易腻
• 西安人太多了

但太原的问题主要是：

• 交通很不方便。虽然也看到它有专门的旅游线路，并且感觉是用心的，但体验上确实还有欠缺。

D1

我们是早上 7.55 的飞机，所以定了个 5.10 的送机，相比打车要贵一点，但好在不需要担心到时候没有车。正好前一天是跨年夜，我们就去雨花台吃了点饭，逛了下雨花万象，就住在雨花了。因为我经典的失眠，导致那一天我实际上没怎么睡。

在机场躺大座睡了一个小时，然后登机门开了，风吹进来冷的要死，没法继续睡了。好在也快登机了。这鬼飞机是摆渡车，真的冷死，外面还下着雪。

到了机场，出门就能打车，打车秒打，司机就在停车场，很快就上了车。太原机场离市区是真的近，离太原南站也很近，所以是非常适合中转的城市，这很类似之前去过的张家界。

北齐壁画博物馆分为三个展厅：

• 第一展厅是娄叡墓的壁画。比较有印象的一个是狩猎图，一个是升天图。有印象的细节一个是马一边跑一边被吓得拉屎。另一个是雷公，长得特别奇怪。
• 第二展厅徐显秀墓。因为整个博物馆实际上就是盖在这个墓上面的，所以比较有趣。我们可以看到当时发现这个墓的土丘上的盗洞。值得一提的是，虽然我们没法下到最下面的墓里面去，但是旁边有个清晰度贼高的 vr 可以看，不仅壁画很清楚，而且能看到总共五个盗洞。我想，为什么我们看不到棺椁，可能就是这么多盗洞把它们都偷走了了吧。另外，后面在山西博物院中，我们能看到这个墓里面的壁画，但不知道是仿制品，还是移过来的。
• 第三展厅是拼好展，里面展示了不同的墓的壁画。

从北齐壁画博物馆出来，打车非常难打。索性看到有个公交车，就上去，发现好像是个旅游专线，只到双塔公园和火车站。用微信乘车码就可以刷码，坐上去之后，司机一个人发了一张门票一样的东西，实际上就是旅游专线的车票，感觉挺用心的。

考虑了下，我们觉得先回宾馆比较好。一来，双塔公园离着纯阳宫和宾馆都很远，后面两者反而比较近。二来，我那个包确实太重了。于是打了辆车，直奔宾馆。

到了宾馆，准备出门，发现山西博物院突然放了一千多张票。于是打电话问，答复说只要是今天的时间预约的就可以来。接线的是个女人，用非常热情的预期表达了对我们的欢迎，非常点赞。所以，我们临时改了计划，去看山西博物院。

山西博物院就靠着我们的亚朵，中间隔了自然博物馆和图书馆。走过去的时候，门口就排了个小队了。进去之后，发现博物馆里面全是人。这个博物馆主要是四层，重点的是在 2/3 两层，另外有几个重要展物被放到了第 1 层和第 4 层。山西博物馆主要就是看各种青铜器。四楼有很多主体展厅，比如玉、应县木塔、钱币等。总体感觉这博物馆年代比陕历博要老，基本上全是青铜器。比较有印象的一个是那个猫头鹰，还有就是大蜗牛上骑着小蜗牛，以及博物馆徽标上的大鸟上骑小鸟的。有个叫雁鱼铜灯的文物好像被国博借走了，直接在下面放了个不知道是啥的青铜器掩耳盗铃。

从山西博物馆出来，快五点了，我们赶快打车去河东颐祥阁。事实证明这决定很正确，因为我们到的时候饭店还没开门。但是我们刚坐下来，一堆人就陆陆续续进来了，然后他们就要排队。我们在饭店点了非常多的东西，在此点评一下：

• 涮肚 我老婆说这个麻辣烫很好，因为里面的麻酱没有麻酱味，她能接受。我觉得也不错。
• 芥末凉粉 很爽口。
• 风葫芦 感觉是炸的一个脆皮球，然后里面是很嫩的鸡蛋。我对象很喜欢，我觉得还行，但没有特别很好吃。
• 黄米排骨 这个是最贵的，但吃起来感觉一般。
• 麻辣串 实际上就是豆干，但是加了他那个口感很椒麻胡辣的汤汁，很好吃。我对象不喜欢胡椒和辣口味，她不怎么喜欢。
• 羊腿 我觉得很好吃，我对象也觉得。而且她觉得不太膻。
• 槐花 小学里课文学过，但实际上是第一次吃槐花，感觉挺好吃的。没想到是咸的，感觉有点吃野菜的感觉，但并不像野菜那样有茎的感觉。
• 野菜丸子 感觉就是北方的那种丸子。
• 绿豆糕 挺甜的，但是很好吃。
• 烧饼 有点像肉夹馍的馍，但是是很热的，吃起来很香。

从颐祥阁出来，已经打包了一堆东西，我们打算去鼓楼街再去看看。太原的地铁在长风街这一段特别稀疏，但吃的又都在这里，所以我们走了好远上了地铁。从府西街站下来，我们拐进了帽儿巷。

刚去的时候，人是一般多，我老婆还说这个离长沙差远了。我们随便走走，就看到一家要排队的卖麻花的，说特别有名。买了黑芝麻和蜂蜜的，感觉就是小时候的味道，有点类似于我奶奶买的那个火腿肠面包。我记得那个面包皮我特别喜欢，就是这个麻花的味道。

我们后面又买了枣糕和碗托。碗托的那个面感觉挺好吃的，是糯糯的。而很早之前我对象在淘宝买的感觉就很干，跟那种硬胶水一样。不过我当时已经又累又撑，不太吃的下了。

我准备往地铁站走准备回去了，但是我老婆说，这个鼓楼街，我们还没见到鼓楼呢。于是走到横过来的一条街上，这条街就洋气很多了，都是一些洋人的建筑。再往前走，还有一个巨大的钟楼。这里人就开始特别多了，有种长沙的感觉。

在认一力吃了几道菜：

• 羊肉水饺 点了两种，但感觉都一个味道。我老婆说羊肉味特别大，根本没法吃。我觉得还行，但是感觉很咸。感觉羊肉馅里面加了很多葱姜蒜。另外，第二天我从冰箱里面拿出来的时候，感觉它们散发着一股呕吐味。但加热之后，又能吃了，感觉还行。
• 沙棘醪糟 感觉挺好吃的，很清淡，不是特别的酸，也不怎么甜。但是很爽口。
• 头脑 头脑里面的羊肉挺好吃的，炖的烂。但是那个粥一样的东西就是一言难尽了。吃起来感觉就好像是熬的很浓的羊油和粥一起煮成的粘稠物。但是呢，它本身又不具备酸甜苦辣咸这些基础的味道，所以吃在嘴里就是一股腥味。

从认一力出来，人就开始比肩接踵了，于是我们准备往回走了。当时我已经又撑又困到神志不清了，终于走到了柳南地铁站。坐地铁到太原理工大学站，发现到酒店还要走好远。

晚上回来困得要死，倒头就睡。中途 23 点的时候被老婆叫起来看，原来是酒店对面就放起了烟花。话说山西今年不禁止放烟花，所以大家过年都在放，感觉挺热闹的。汾河上的那条龙今天晚上也是一直亮着灯，还挺好看的。

D2

早上起的有点晚，睡了大概 10 个多小时。吃了个酒店的自助餐，顺便把昨天的水饺热了下。

打车去晋祠，这一路挺远的，司机开得贼快。太原的早晨全是雾霾，路过还有几个大烟囱在冒着白气，可能是供暖工厂吧。到了晋祠，寻思着买了个天龙山的门票。晋祠一进去是非常大的免费公园，里面做了一堆假山雕塑啥的，有个唐太宗的雕塑后面还出现在太原的城市宣传画上，但是感觉雕的人脸都一样。

晋祠博物馆是挺有意思的，原本我以为它就是一个祠堂，拍照打卡走人这样，但里面挺大的，而且建筑的排布很好看，基本上处处是景。

游览这个景点，必须要有个讲解。我当时还是用的旅途随身听，感觉讲的是足够了。总而言之，这个晋祠原来是纪念一个儿子的，后来慢慢的，妈妈名气反而更大了，所以改为了主要祭奠妈妈，结果导致儿子的祠堂偏安在整个晋祠的最角落。

一进门就是晋祠最网红的孙悟空同款了，但其实它并不是祠堂，而是一个戏台，叫水镜台。很多人在正面拍照合影，走到背面有个康熙题的匾额。

然后，我们就按照旅途随身听的导览逛了，先逛了一遍关帝庙、岳飞庙等，我也认识了一堆歇山顶、硬山顶等屋顶的类型，从而判断规格。然后就到了儿子的唐叔虞的祠堂。这哥们属实惨，真的就在最角落，门口还贼小。要不是随身听，我可能都不会进去。

从唐叔虞祠堂出来，就看到前面一堆人。这里应该就是晋祠最核心的地方，也就是圣母堂了。圣母堂有几点比较独特：

• 堂前的十字桥，据说是首创。这个桥在晋祠外围的免费公园中也有个拙劣的模仿。
• 七开间的规格，每个柱子上都有龙盘旋，这些龙长得都不一样，有的还很抽象。
• 圣母堂中的宋代雕塑，惟妙惟肖。
• 圣母堂旁边有个周朝的柏树，然后它被另一棵柏树架着。

从圣母堂转了一圈出来，旁边还有一个苗裔娘娘堂，再绕出来，就到了难老泉。这个说是晋阳第一泉，感觉就是比较谦虚了，毕竟无锡还有个天下第二泉呢。这个亭子是北齐建的，所以可以看到斗拱是非常的大。虽然后面在嘉靖年返修了，但仍然是使用了北齐的手法。而它对面的亭子，斗拱就很小，一看就是明清的建筑。其实在晋祠中，分布着不同朝代的建筑，我们都可以从斗拱的大小，以及房顶上鸱吻头和尾巴的比例来分辨年代。晋祠中比较主要的建筑如圣母殿等都是在唐左右建设的。

难老泉会通过一个龙头流到旁边的一条小溪里面，然后很多人排队在那里接水。我们绕过那群人，就可以走到子乔祠、董寿平美术馆那一带，不过那些就不是重点了。

我去逛了逛美术馆，我老婆根本就没去逛，而是再绕回来到正面，到了圣母堂之前的一些建筑，如会仙桥、献殿等。比较有意思的是金人台，上面有个非常小的小楼，不知道那是干嘛的。献殿上面有个万历四年的匾额，我对象说是不是那个万历四年春，我说那是庆历四年春。

从晋祠出来，下一站就是天龙山。但我们必须走很长的路才能穿过外围的免费公园。我们还路过了晋文公艺术博物馆，不过没进去看，不知道里面怎么样。博物馆附近有很多大湖环绕，里面可以划船，但是现在是冬天，这些湖面都结冰了。博物馆前按照先秦的特色，搞了点夯土柱子。绕过博物馆，就到了出口，在这里进行了一些简单的修整，买了个烤红薯和上海阿姨，就去找景区交通。

公交站排队等了比较长的时间，感觉得有至少十分钟，车来了。因为我们觉得不太妙，所以当时就站的比较靠前，所以有座位坐，但没想到这个公交车是不给站的。所以我们眼睁睁看着后面的人上不来，司机跟他们说等下一班吧。这公交车开了，没一会就上了盘山公路。这路应该太原花了很多钱搞了个旅游公路，很多盘山公路被搞成了类似南浦大桥那样的展线，所谓网红桥。这些展线上停了一堆小轿车，人们在那里往低处拍照片。到了龙门站，我们下车，其实已经花了几十分钟了。

这天龙山其实很坑，它主要是看石窟的，分为东峰和西峰，但是我们去的时候东峰全封掉了，所以我们就直接往上走回去了，也没再去下面的天龙寺。具体到西峰石窟，里面也是丢的丢，乱涂乱画的也有。后面打了个车去国宝馆，里面看到了东峰石窟中第 8 窟的佛头，说是被日本人之前抢走了的，后来被中国又追回来了。国宝馆旁边还有个数字馆，就是给你看看一些石窟的宣传片。

从国宝馆直接坐车到晋祠，下了车就打车去植物园。太原植物园很大，一进去是一个湖，湖面已经结冰。围湖种了一圈银杏，叶子很漂亮，不过走近一看发现是假的。因为是冬天，主要能逛的就是几个温室。这几个温室设计的都很好，造景很有一套，并且有高低不同的步道，可以方便游客游览观看不同高度的植物。热带雨林馆里面有个瀑布，大家挤在那里拍照。不过我最喜欢的还是沙生植物馆，一进门是三个大黄柱子，加上远处落日，夕阳照在上面的感觉，给我一种置身于沙漠或者火星表面的感觉。另外还有一个蝴蝶馆，以及一个园艺馆，反正都挺好看的。太原植物园还有萤火虫看，不过冬天就暂停了。

最终也没等到植物园那个网红天花板亮灯，而是五点二十不到就打车走了。当时打车很容易，不过刚开到市区就发现植物园门口堵红了。我觉得这里的交通设计有问题，汽车要去植物园门口，实际上要走很远到前面掉头才行。这也是太原的一个特点，快速路很多，但是跨越高速路，或者掉头，就很麻烦了。

去吃东北爱情麻辣拌，在一个非常荒芜的小巷中的破落小平房，里面墙上天花板上都是之前顾客的留言。只能选择加料，以及辣度。我加了麻花和什么的，我对象加了另外一种。这麻辣拌全是素的，全是碳水，要不就是豆制品。旁边一个京爷在吹牛逼说自己老爹是个煤矿里面的啥科长，然后后面北京就不让挖煤了 blabla，说房子贵得要死，幸亏买得早。

从麻辣烫出来，不远就能走到附近的上帝炸鸡，因为我觉得尽管有外卖，但是没必要一定吃总店。路上还遇到一个卖碗托的路边摊子，不过这次卖的是保德碗托。味道很不一样，我看到她加了一种黄色的酱汁，我想这个应该导致了我们最终吃到的是有点酸味的。加上我们没有要很多辣油，就导致碗托并不腻。不过它的面感觉就和淘宝的荞麦面碗托一样，不如昨天的那个有糯劲。卖碗托的斜对面就是上帝炸鸡，我们点了一份大份的，吃起来感觉就是那种老派炸鸡的感觉，外皮特别脆，但是里面很多汁。不过我觉得得加点辣粉更好吃。

买完上帝炸鸡，就去利源沾片子。中途路过似乎是太原比较繁华的体育路街区，有个盒马。我们继续往北走就到了沾片子，在一个灯光很暗的小街上。我老婆先去的，然后出来告诉我要排位，留了个电话号码。然后我们就寻思附近转转，这附近可真没啥能转的。一些很拉胯的咖啡厅，泰山啤酒，一堆成人用品店。最后，我们回到那个店，发现人都换了一遍，显然老板看生意好，就没有叫我们。所以我们被迫在店里面站着等位，等的时候，后面最多来了四队人。老板让我们提前点菜，我们点了一堆：

• 沾片子 吃起来比较素。我比较喜欢豇豆的那个，感觉保留了蔬菜的本味。
• 炒茄子 很好吃，茄子很脆，酱汁很香。
• 莜面
• 清徐灌肠 实际上也是素的，感觉挺油的

这家店不光等位慢，做得也慢，出来了就九点多了。打车不太打得到，所以就准备坐地铁，路上还买了一盒草莓，大个的，才 30 块钱。好不容易坐上了地铁，然后下错站了，所幸直接打车算了。不过这样晚上在汾河边散步的计划就泡汤了，实际上那天晚上步道的灯光包括那条龙也没开，所以就算了。

D3

早上七点五十就起来了，先把昨天的炸鸡拿到宾馆餐厅里面热热，顺便再吃吃他的刀削面和豆花。太钢汽水也是尝了尝别的味道，感觉都还可以。

吃完饭，就去汾河边散散步。这次见识到了传说中的自行车道，其实挺窄的，一个方向只能容纳一个人骑。并且这个自行车道的下匝道有点少，很多地方是高架。要散步的话，可以穿过自行车道再往河边走。

逛完回去已经快九点半了，赶快打车去晋商博物馆。晋商博物馆实际上就是原来的巡抚衙门，在民国时期也是山西的中枢所在，到了新中国，一度是省委和省政府的办公地，一直到 2017 年改建为博物馆。这个博物馆确实透露着政府办公室的气息，特别是中间一栋苏联式样的办公楼，一进去就能闻到浓烈的复写纸的味道。

我发现山西这边的博物馆有一个喜好，就是搞大全套收集。例如山西博物院就搞了个钱币展，非常夸张的收集了先秦时期各个国家的钱币，以及后面历朝历代不同年号的钱币。晋商博物馆中更是收集了七八套大小不一的编钟，收集了鼎、盆、壶、斛等各种器皿。最特别的是，我第一次看到了一个东西叫灶。晋商博物馆挺长的，进去先是一个高楼，里面存了据说是山西第一巡抚诺敏的匾额。后面是2号楼和3号楼，两栋楼通过走廊连在一起。在后面是个会议室，和一个苏联样式的高楼。再往后有一个钟楼，但是不让过去了。比较幸运的是，东花园原来在修缮，但是这一次对我们开放了。进去可以看到民国时候的一些陈列，以及五几年的时候省委书记的住房。

从晋商博物院出来，就去吃了一诺铜火锅。我老婆照例点了一辈子都吃不完的菜，点评如下：

• 铜锅 感觉一般
• 黄米凉糕 很好吃，但是不要把上面的糖拌进去，不然就太甜了
• 丸子串 一般
• 羊肉串 很好吃
• 涮肚 感觉很好吃，我老婆觉得麻将很多，但是我觉得跟颐祥阁一模一样
• 蒜泥茄条 挺好吃的，酸酸甜甜
• 小酥肉 肉感觉一般，但是旁边的蘑菇还不错
• 烤饼 感觉很好吃，也带回去了
• 鸡包豆腐 感觉就是千页豆腐？一般
• 过油肉 很好吃
• 酸辣白菜 酸酸甜甜的很好吃

吃完饭，才 12.40，感觉还有一段时间，因此就准备去纯阳宫。因为我在打车过来的路上就看到纯阳宫了，所以就直接骑车过去，风风火火，花了不到十分钟就骑到了。进去之后，我老婆终于要上厕所了，我先进去逛。它的展厅都好没意思，啥陈列都没有，就干放视频。走到最后，是个主题展，里面陈列了一个常阳天尊像，居然是一级国宝，并且是 195 文物。这玩意也没有被框起来，能够近距离观赏感觉挺好，大家也都很有素质，不上手摸。出门，上楼梯，二层的展览就很蠢了，有个展厅里面全是文物已借出。二楼可以通到前面的九宫八卦院，有很多人在那边拍照。

往回走，打开了旅途随身听，介绍了九宫八卦院，这个建筑布局很有意思，据说是全国唯一的。再往回，就是吕洞宾殿，也就是纯阳宫的主要建筑。再往回就是弥勒佛铜像。我老婆跟我说这里面有个西汉的石狮子，还有明代的铜狮子，居然就直接摆在那里，也没有保护，感觉山西还是富，人们和文物生活在一起。

再往回走，就快到了出口。此时左边是一个假山，上面是一个关羽像。关羽像没有胡子，因为这个像是在明朝的，而关羽有胡子的说法是明末根据三国演义才有的。右边是个碑廊，然后里面放着另一个 195 文物，涅槃变相碑。这玩意也没有被保护起来，我觉得还是不太好，毕竟这个是室外嘛，还是要有点防护为好。

我在看涅槃变相碑的时候，因为空间狭小，我的书包还把后面的一个壁画的说明牌给蹭下来了，幸亏没有伤着壁画，不过这也说明了这个陈列比较拥挤，容易碰到。

从纯阳宫出来立马打车赶往机场，不得再次羡慕太原机场离市区实在是近。

• 针对这些问题的技术性解法和运维性的解法
  涉及到某些内部知识的将不予公开。
• 对于问题严重程度应该如何判断
• 如何为了达成上线的既定目标，设计临时性的缓解措施

POC on TiDB-X for Customer U, late Nov 2025

主要问题

1. 支持 Keyspace
2. 运维手段
   包含 Shard、Reader 和 Importer
3. 支持 Security
4. openssl 的编译问题
5. arm 编译的问题
6. 上线后出现的影响可用性的 bug
7. 上线后出现的影响性能的 bug

Nov 21

讨论 import into 场景下，如果某个 worker 因为 OOM 重启，则因为目前缺少 Heartbeat 机制和 reschedule 机制，整个任务会因为这个小任务失败而停止。

另外，也提到了和 import into 流控相关的问题。

Nov 23

遇到了 tokio Sender 报错 channel closed 问题。当时没有空查。

这个问题实际上就是协程因为哪里 unwrap 而 panic 了，而因为协程池是跑的消息循环，所以 panic 了不 join 也不知道。一直没找到是哪里，后来我加了点 panic hook，才在 Nov 30 定位到是服务发现的问题。

Nov 26

1. TLS options are only supported with HTTPS URLs
   这个错误很 plain
2. Client had asked for TLS connection but TLS support is disabled. Please enable one of the following features: [“native-tls-tls”, “rusttls-tls”]
   我们不能用 native，只能用内置的 rusttls
3. undefined symbol: pthread_atfork
   ARM 上的编译问题，有专门文章介绍
4. TLS error error:0A000086
   这个就是要启动的时候指定下用 ring 还是 aws_lc_rs

Nov 27

1. 排查 ARM 上的问题，这里做了两套方案，先设法用 x86 跑起来。这证明也是正确的，白天我们发现了更多的问题，最终因为 TLS 的问题也没有跑起来。但是晚上我们把 ARM 验证了下，发现不报原先的错了。
2. 遇到一个新问题是我们的云上 operator 机制不支持改参数，我们挂的又是 ro 文件系统，导致很难验证
3. etcd client unavailable or unhealthy, attempting reconnect
   这个是 kebab-case 的锅，Rust 和 C++ 的格式不一样，写配置的同学把 ca-path 写成 ca_path 了。
4. 后来发现，TiFlash CN 还是绕不开 TLS 的问题。所以还是得兼容。

Nov 28

1. get meta channel failed times
   这个错误还是 etcd client 的 ca-path 没传对
2. 到这里为止，整体看上去能跑了，但是查询报错，看日志感觉核心服务没起来
   首先 lsof 看了一下，发现服务器都没起来。
   因为没有 panic，直觉是哪里有个报错死在协程里面没传播出去。进而发现是 rust 的 grpc server 不能在 dns 格式的 url 上启动。不得不说我几天前的 advertise_addr 的改动很有先见之明 https://github.com/pingcap-inc/tici/pull/515

Nov 29

1. 白天是在 import into 导入数据，晚上出现了一堆问题。
2. 首先，是之前的那个 panic 导致协程退出的阴魂不散又来了。我紧急去掉了一堆 unwrap，并且加了 panic hook 打印错误日志。
3. 然后，是 writer 那边没有对 meta 返回的错误码进行处理，但是加上了处理之后，一个集成测试不通过了。大家觉得要不就把这个测试禁用了吧，但是我很反对，因为这个测试是唯一一个带上真实的 worker 和 reader 跑完 e2e 的测试。并且我看了日志发现一个 writer node 被超时移出了，所以尽管 pr owner 认为他并没有改动到这一块的逻辑，我仍然认为他的修改导致一个严重问题暴露了。因此，我们应该先查问题。原因是即使我们强行合并了，也不能拿这个 commit 去跑生产。后来，确实发现了是在处理 heartbeat 的时候会等待一个异步任务结束，所以导致后面 heartbeat 消息循环直接卡死了。所以，这个问题确实会导致 writer 因为丢失心跳从而被全不 failover，进而整个集群没有 writer 可用的 critical 问题。不 approve 这个 PR 是完全正确的。

Nov 30

今天主要切换到性能方面的支持上：

• warmup 的速度太慢了，所以想把这一块改成并发执行
  在这个处理之后，8 个节点，24 个并发，大概是不到两个小时就处理完毕了。
• 因为 worker 出现了异常重启，导致重启后 meta 向它发送了大量的 add shard message，导致触发了 grpc 的消息大小上限。临时通过增加上限来 workaround 了。实际上是可以通过拆成多个 heartbeat response 来解决。另外同事也提到，可以只发部分信息，其他的后续让主动请求，但这个可能会产生很多的 grpc 调用。

Dec 1

• 发现查询速度比较低，原因是串行访问的所有 shard

Dec 2

• 发现查询并发比较低，原因是查询的 filter 不能通过主键进行过滤，所以导致每次查询需要访问所有的 shard

Dec 3

• 关于昨天的并发问题，认为一个 shard 中有多个 fragment，并且一个 fragment 中又有多个 segment，因此会影响查询的速度。通过 Manual compaction 和调大内存的方式，使得 fragment 和 segment 都变少。
• 因为目前没有自动 balance 机制，所以还需要 Manual reschedule。

Dec 5

功能侧：

• 主要处理 duplicate fragment 的问题。我认为因为 apply compaction 需要根据 frag path 来定位，重名的 frag 会导致问题，所以应该由 meta 来禁用。

测试侧：

• 执行了 Compaction，并且后续自动执行了 Merge，发现查询 QPS 提高了 50%，但依然是比较差的
• 因此决定用 (token0_address, ts) 作为新的主键，和 TiKV 解耦

Dec 6

这一轮测试发现调整了新的主键之后，QPS 增加了很多，可以看出列存中使用不同的 Sharding key 的重要性：

• 静态数据 QPS 2.6k+，P999 61.6 ms，且仍有弹性。其中 TiFlash CPU 是 2300%，内存是 8 * 91G。
  https://github.com/CalvinNeo/ue-bench/blob/master/src/main.rs

  1	SELECT * FROM ... WHERE token0_address = ? AND platform = ? AND ts < ? LIMIT 5

1

/tiflash/tiflash: symbol lookup error: /tiflash/libtici_search_lib.so: undefined symbol: pthread_atfork

首先，ldd 看到，链接的是本地的 /lib64/libpthread.so.0。

可以通过 strings /lib64/libpthread.so.0 | grep '^GLIBC_' 命令查询 GLIBC 的版本。

然后，nm 了一下 /tiflash/libtici_search_lib.so，结果是：

1. x86 开发机

   1 2 3 4 5 6 7 8

   nm libtici_search_lib.so | grep pthread 0000000003c97e70 t __pthread_atfork 0000000003c97e70 t pthread_atfork U pthread_attr_destroy U pthread_attr_getguardsize U pthread_attr_getstack U pthread_attr_init U pthread_attr_setstacksize

2. arm tiflash:v2025.8.10-2-gc9e3144-centos7 镜像
   

3. x86 tiflash:v2025.8.10-2-gc9e3144-centos7 镜像
   这个是 multi arch 镜像，但是 glibc 版本不一样

那么这个符号在 /lib64/libpthread.so.0 里面有么？nm 了一下：

• x86 的版本是 2.34，显示这个 so 是没有 Debug info 的。难道被 trim 了么？ls 了一下这个文件，发现只有 15KiB 左右。后来了解到，在较新的 GLIBC 中，pthread 相关的被整合到了 libc.so 中，我 nm 了 libc.so 确实可以看到。
• arm 版本是 2.17，nm 了可以看到其他 pthread 符号，但是看不到 pthread_atfork。

原因是在大多数 Linux 发行版（使用 glibc 的系统）中，pthread_atfork 的符号并不在常规的共享库如 libpthread.so.0 中，而是通过链接器脚本特殊处理，其具体实现位于 libpthread_nonshared.a 这个静态归档文件中，而非 .so 文件里 。

解决方案参考 https://github.com/pingcap/tiflash/pull/10571，强制使用 -pthread 而不是 -lpthread 即可。

mpsc

mpsc 有 bounded 和 unbounded 两种形式。通过不同的 semaphore 来区别。

Chan 结构

对于 unbounded semaphore，其最低的 bit 表示这个 channel 有没有关闭。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

// ===== impl Semaphore for (::Semaphore, capacity) =====

impl Semaphore for bounded::Semaphore {
    fn add_permit(&self) {
        self.semaphore.release(1);
    }

    fn add_permits(&self, n: usize) {
        self.semaphore.release(n)
    }

    fn is_idle(&self) -> bool {
        self.semaphore.available_permits() == self.bound
    }

    fn close(&self) {
        self.semaphore.close();
    }

    fn is_closed(&self) -> bool {
        self.semaphore.is_closed()
    }
}

// ===== impl Semaphore for AtomicUsize =====

impl Semaphore for unbounded::Semaphore {
    fn add_permit(&self) {
        let prev = self.0.fetch_sub(2, Release);

        if prev >> 1 == 0 {
            // Something went wrong
            process::abort();
        }
    }

    fn add_permits(&self, n: usize) {
        let prev = self.0.fetch_sub(n << 1, Release);

        if (prev >> 1) < n {
            // Something went wrong
            process::abort();
        }
    }

    fn is_idle(&self) -> bool {
        self.0.load(Acquire) >> 1 == 0
    }

    fn close(&self) {
        self.0.fetch_or(1, Release);
    }

    fn is_closed(&self) -> bool {
        self.0.load(Acquire) & 1 == 1
    }
}

无论是 unbounded 还是 bounded，最终都是到 chan::Tx 和 chan::Rx 这两个结构里面。这两个类都持有一个 Arc<Chan<T, S>>。

我们会看到有两个 Tx：

1. chan::Tx 是一个 Arc<Chan<T, S>>，它实际上封装了 Chan，更上层一点
2. list::Tx 是一个 Block 的链表。它是 Chan<T, S> 的 filed，更底层一点

list::tx 是一个无锁队列。这个队列的内存是以 Block 为基础分配的，每个 block 能装 const BLOCK_CAP: usize = 32; 个 Value。所以，Chan 中实现了解耦：

• list 模块只负责无锁队列的实现
• Chan 的其他部分负责容量控制、notify/waker 的逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

pub(super) struct Chan<T, S> {
    /// Handle to the push half of the lock-free list.
    tx: CachePadded<list::Tx<T>>,

    /// Receiver waker. Notified when a value is pushed into the channel.
    rx_waker: CachePadded<AtomicWaker>,

    /// Notifies all tasks listening for the receiver being dropped.
    notify_rx_closed: Notify,

    /// Coordinates access to channel's capacity.
    semaphore: S,

    /// Tracks the number of outstanding sender handles.
    ///
    /// When this drops to zero, the send half of the channel is closed.
    tx_count: AtomicUsize,

    /// Tracks the number of outstanding weak sender handles.
    tx_weak_count: AtomicUsize,

    /// Only accessed by `Rx` handle.
    rx_fields: UnsafeCell<RxFields<T>>,
}

block 的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#[cfg(all(target_pointer_width = "64", not(loom)))]
const BLOCK_CAP: usize = 32;

#[repr(transparent)]
struct Values<T>([UnsafeCell<MaybeUninit<T>>; BLOCK_CAP]);

pub(crate) struct Block<T> {
    /// The header fields.
    header: BlockHeader<T>,

    /// Array containing values pushed into the block. Values are stored in a
    /// continuous array in order to improve cache line behavior when reading.
    /// The values must be manually dropped.
    values: Values<T>,
}

/// Extra fields for a `Block<T>`.
struct BlockHeader<T> {
    /// The start index of this block.
    ///
    /// Slots in this block have indices in `start_index .. start_index + BLOCK_CAP`.
    start_index: usize,

    /// The next block in the linked list.
    next: AtomicPtr<Block<T>>,

    /// Bitfield tracking slots that are ready to have their values consumed.
    ready_slots: AtomicUsize,

    /// The observed `tail_position` value *after* the block has been passed by
    /// `block_tail`.
    observed_tail_position: UnsafeCell<usize>,
}

看 Block::grow，就是一个无锁链表的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

...
        let mut curr = next;

        // TODO: Should this iteration be capped?
        loop {
            let actual = unsafe { curr.as_ref().try_push(&mut new_block, AcqRel, Acquire) };

            curr = match actual {
                Ok(()) => {
                    return next;
                }
                Err(curr) => curr,
            };

            crate::loom::thread::yield_now();
        }
...

为什么是关于 Block 的无锁队列？

为什么是关于 Block 的无锁队列，而不是关于 Value 的呢？

1. 减少锁竞争和原子操作 (Reduced Contention and Atomic Operations)
   集中操作 (Batch Operations): 在高并发场景下，如果每次发送一个 Value 就需要对共享队列（如链表或原子指针）进行一次原子操作（例如 CAS - Compare-and-Swap）来添加节点，那么多个发送者 (Multi-Producer) 之间的竞争会非常激烈，导致性能瓶颈。
   Block 机制: 使用 Block（块），每个 Block 中可以存放多个 Value。这样，发送者可以一次性分配一个 Block，并填充多个 Value。在将这个 Block 链接到队列末尾时，只需要进行一次原子操作来更新队列的尾指针。这大大减少了对核心共享数据结构（队列头/尾）的原子操作次数，从而降低了锁竞争和系统开销。
   局部性 (Locality): 一旦一个发送者成功获取并填充了一个 Block，它就可以在没有竞争的情况下，向该 Block 中写入若干条消息，这利用了 CPU 缓存的局部性原理。
2. 优化内存分配 (Optimized Memory Allocation)
   批量分配: 每次发送一个 Value 就进行一次内存分配是低效的。Block 允许一次性分配一块较大的内存，用于存储多个 Value。
   更少的元数据: 如果每条 Value 都是一个独立的链表节点，那么每个节点都需要存储一个指针（指向下一个节点）作为元数据。在 Block 方案中，只有 Block 之间有链接指针，一个 Block 内部的多个 Value 可以紧凑存储，减少了内存开销。

channel 创建

send 实现

unbounded

unbounded 的 send 的实现，可以看到，最终调用了 Chan 的 send，后面会详细介绍。

1
2
3
4
5
6
7
8

pub fn send(&self, message: T) -> Result<(), SendError<T>> {
    if !self.inc_num_messages() {
        return Err(SendError(message));
    }

    self.chan.send(message);
    Ok(())
}

inc_num_messages 的逻辑如下，主要是每次增加 2，保证末尾是 0

1
2
3
4
5

if curr & 1 == 1 {
return false;
}

.compare_exchange(curr, curr + 2, AcqRel, Acquire)

bounded

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

async fn reserve_inner(&self, n: usize) -> Result<(), SendError<()>> {
    crate::trace::async_trace_leaf().await;

    if n > self.max_capacity() {
        return Err(SendError(()));
    }
    match self.chan.semaphore().semaphore.acquire(n).await {
        Ok(()) => Ok(()),
        Err(_) => Err(SendError(())),
    }
}

pub fn max_capacity(&self) -> usize {
    self.chan.semaphore().bound
}

pub(crate) fn acquire(&self, num_permits: usize) -> Acquire<'_> {
    Acquire::new(self, num_permits)
}

Chan 的 send 实现

Chan 的 send 的实现如下

1
2
3
4
5
6
7

fn send(&self, value: T) {
    // Push the value
    self.tx.push(value);

    // Notify the rx task
    self.rx_waker.wake();
}

这个 rx_waker 是一个 AtomicWaker 对象。

1
2
3
4

pub(crate) struct AtomicWaker {
    state: AtomicUsize,
    waker: UnsafeCell<Option<std::task::Waker>>,
}

Reference

• 完备性
• 唯一性

Case by case

如何表示一个空区间？

有一些 string，那么可以用 [s1, s2) 来圈出一些 string。因为是左闭右开区间，所以空集难以表示。这里只能通过

如何表示“和上次一样”

Option<Vec> 还是 Vec？

Vec 是 Option 的上位类型。

1.0 Introduction

Linux 的读写 API 经历了：

• read

• pread：增加了 offset

• preadv：offset 是 iovec 的形式，就是支持分散读

  1 2 3 4 5

  struct iovec { void __user *iov_base; __kernel_size_t iov_len; };

• preadv2：加了 flags
  可以参考 https://www.man7.org/linux/man-pages/man2/preadv2.2.html

但上述的 API 都是同步的。posix 有 aio_ 系列的 API 标准，但是没啥人用，性能也不好。

Linux 有个 libaio，它和 POSIX 的 aio_ 系列不是一个东西。但它也有问题：

• 它要求 O_DIRECT，不然就和同步调用没啥区别。而 O_DIRECT 会 bypass cache，并且有严格的对齐要求，所以用途受限制。

• 即使满足 async 的所有条件，最终也不一定是 async 的。比如：

  • 如果要修改元数据，可能会 block
  • storage device 的 request slots 的数量是固定的
    这里的 request slots 表示 storage device 同时可以处理的并发数。
    传统存储协议如 SATA、SAS 中，只有一个命令队列，存放未完成的 io，它的长度就是 io depth。如果下层 storage device 的 request slots 数量小于 io depth，那么 io 请求就可能在 io 队列中等待。
    NVMe SSD 支持多个 Submission Queues (SQ) 和 Completion Queues (CQ)，每个 SQ 条目可对应一个正在执行的 I/O 命令。比如有 64 个 queue，每个 queue 深度是 1024，那么理论上最多可并行执行 64 × 1024 = 65536 个命令。

• 提交一个 io 需要复制 64 + 8 bytes。完成一个 io 需要复制 32 bytes。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

  struct iocb { __u64 aio_data; __u32 PADDED(aio_key, aio_rw_flags); __u16 aio_lio_opcode; __s16 aio_reqprio; __u32 aio_fildes; __u64 aio_buf; __u64 aio_nbytes; __s64 aio_offset; __u64 aio_reserved2; __u32 aio_flags; __u32 aio_resfd; }; struct io_event { __u64 data; __u64 obj; __s64 res; __s64 res2; };

  Depending on your IO size, this can definitely be noticeable.
  IO always requires at least two system calls (submit + wait-for-completion), which in these post spectre/meltdown days is a serious slowdown.

2.0 Improving the status quo

一开始有一些改良 libaio 的工作：

• If you can extend and improve an existing interface, that’s preferable to providing a new one.
• It’s a lot less work in general.

libaio 主要有三个接口：

• io_setup
• io_submit 用来提交一个 io
• io_getevents 用来等待完成，并收获结果

后面觉得，这种改良会把接口改得非常复杂，而且只能解决上面列出的一个问题。

3.0 New interface design goals

• Easy to use, hard to misuse.
• Extendable. 希望这个接口不止支持 block oriented IO。对于网络，和非块存储设备，它都能适用。
• Feature rich. Linux aio caters to a subset (of a subset) of applications. I did not want to create yet another
  interface that only covered some of what applications need, or that required applications to reinvent the same
  functionality over and over again (like IO thread pools).
• Efficiency. While storage IO is mostly still block based and hence at least 512b or 4kb in size, efficiency at those
  sizes is still critical for certain applications. Additionally, some requests may not even be carrying a data payload.
  It was important that the new interface was efficient in terms of per-request overhead.
• Scalability. While efficiency and low latencies are important, it’s also critical to provide the best performance
  possible at the peak end. For storage in particular, we’ve worked very hard to deliver a scalable infrastructure. A
  new interface should allow us to expose that scalability all the way back to applications.

4.0 Enter io_uring

首先是摘录作者的感言，性能必须从一开始，在设计接口的时候就考虑。

Despite the ranked list of design goals, the initial design was centered around efficiency. Efficiency isn’t something that can be an afterthought, it has to be designed in from the start - you can’t wring it out of something later on once the interface is fixed.

作者认为，新的设计要避免 submission 和 completion 事件在内核和用户空间之间的复制，也要避免 indirection，所以他由浅及深得出了下面几点：

1. 内核和用户空间需要 share 这些结构
2. 因此，这些结构应该在内核和用户的共享内存中
3. 因此，必须要去维护这里面的同步关系
4. 如果要用锁，那么就肯定会有系统调用，系统调用肯定 overhead 就大了
5. 因此，single producer single consumer ring buffer 是适合的

考虑到对于 submission 事件，用户是生产者，内核是消费者；而 completion 事件则相反。所以需要两个队列：SQ 和 CQ。

4.1 DATA STRUCTURES

cqe 的后缀表示 Completion Queue Event。

1
2
3
4
5
6

struct io_uring_cqe {
   // 从 submission 中透传过来
   __u64 user_data;
   __s32 res;
   __u32 flags;
};

sqe 则复杂很多

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

struct io_uring_sqe {
   // 操作类型，例如 IORING_OP_READV 表示向量读
   __u8 opcode;
   __u8 flags;
   __u16 ioprio;
   __s32 fd;
   __u64 off;
   // 指向内存地址，如果是向量读写，则指向一个 iovec array 的地址
   __u64 addr;
   // 表示长度，或者 iovec array 的长度
   __u32 len;
   union {
      __kernel_rwf_t rw_flags;
      __u32 fsync_flags;
      __u16 poll_events;
      __u32 sync_range_flags;
      __u32 msg_flags;   
   };
   __u64 user_data;
   union {
      __u16 buf_index;
      // 64 bytes 对齐
      __u64 __pad2[3];
   };
};

4.2 COMMUNICATION CHANNEL

SQ 和 CQ 的 indexing 是不太一样的，先从简单的 CQ 开始。

cqe 是一个内核和用户共享的 ring buffer，内核写会更新 tail，用户读会更新 head。ring buffer 的大小是 2 的幂，它的好处我在 Redis底层对象实现原理分析中有所解析。

如下所示，head 是可以自然溢出的。当然，正如我在 libutp源码简析或者ATP中的实现那样，当 tail 比 head 小的时候，我们也可以认为发生了溢出。
cqring->cqes 是被共享的结构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

unsigned head;
head = cqring->head;
read_barrier();
if (head != cqring->tail) {
   struct io_uring_cqe *cqe;
   unsigned index;
   index = head & (cqring->mask);
   cqe = &cqring->cqes[index];
   /* process completed cqe here */
   ...
   /* we've now consumed this entry */
   head++;
}
cqring->head = head;
write_barrier();

SQ 这边，就是用户生产，内核消费了。之前说到，SQ 的 indexing 不一样，它是有个 indirection 的。submission 的 ring buffer 中存放了 index，索引到 sqe 中的位置。例如下面的例子中，提交顺序是：sqe5 → sqe2 → sqe3。

1
2

SQ array: [5, 2, 3]
SQEs:     [sqe0, sqe1, sqe2, sqe3, sqe4, sqe5]

在文章中，作者提出一个好处是可以将 request units 放到 internal structure 中，我理解就是后面看到的自定义的 app_sq_ring。另外，也能允许在一个操作中提交多个 sqe。我理解就是如下代码所示，先 fill sqe，再写 array 的操作。

1
2
3
4
5
6
7
8
9
10
11
12
13

struct io_uring_sqe *sqe;
unsigned tail, index;
tail = sqring->tail;
index = tail & (*sqring->ring_mask);
sqe = &sqring->sqes[index];
/* this call fills in the sqe entries for this IO */
init_io(sqe);
/* fill the sqe index into the SQ ring array */
sqring->array[index] = index;
tail++;
write_barrier();
sqring->tail = tail;
write_barrier();

只要 sqe 被内核消费了，application 就可以复用 sqe entry，即使内核还没有完全处理完毕，内核会在需要的时候复制这个结构。

这样，sqe 的生命周期就比较短，而 application 可能会发送更多的 submission，从而导致 CQ ring 可能溢出。所以默认下的 CQ ring 的大小是 SQ ring 的两倍。

Completion events 可能以任意顺序到达，它和 submission 的顺序是没有关系的。SQ 和 CQ 两个 ring 是独立运行的。但是每个 submission 事件和每个 completion 事件都能一一对应。

5.0 io_uring interface

下面介绍的是 io_uring 的“裸”接口，即 system call。

io_uring_setup

entries 的取值是 1..=4096，表示 sqe 的数量，必须是 2 的幂。

1

int io_uring_setup(unsigned entries, struct io_uring_params *params);

params 如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

struct io_uring_params {
   // 由内核填写，表示支持多少个 sqe
   __u32 sq_entries;
   // 由内核填写，表示支持多少个 cqe
   __u32 cq_entries;
   __u32 flags;
   __u32 sq_thread_cpu;
   __u32 sq_thread_idle;
   __u32 resv[5];
   struct io_sqring_offsets sq_off;
   struct io_cqring_offsets cq_off;
};

struct io_sqring_offsets {
   __u32 head; /* offset of ring head */
   __u32 tail; /* offset of ring tail */
   __u32 ring_mask; /* ring mask value */
   __u32 ring_entries; /* entries in ring */
   __u32 flags; /* ring flags */
   __u32 dropped; /* number of sqes not submitted */
   __u32 array; /* sqe index array */
   __u32 resv1;
   __u64 resv2;
};

io_uring_setup 返回的 int，实际上是一个 fd。如之前所说，这个 fd 是被内核和用户共享的。而 sq_off 和 cq_off 就表示了这共享内存中，SQ 和 CQ 的位置。

1
2
3

#define IORING_OFF_SQ_RING          0ULL
#define IORING_OFF_CQ_RING  0x8000000ULL // 128MB，指的那个 index 数组
#define IORING_OFF_SQES    0x10000000ULL

用户可以自定义 sq ring 的结构，这个结构中的每个字段都是一个指向到共享内存中位置的指针

1
2
3
4
5
6
7
8
9

struct app_sq_ring {
   unsigned *head;
   unsigned *tail;
   unsigned *ring_mask;
   unsigned *ring_entries;
   unsigned *flags;
   unsigned *dropped;
   unsigned *array;
};

如下面的 setup 所示，可以看到自定义的 sring 是如何通过 ptr 和 sq_off 组装起来的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

struct app_sq_ring app_setup_sq_ring(int ring_fd, struct io_uring_params *p)
{
   struct app_sq_ring sqring;
   void *ptr;
   ptr = mmap(NULL, p->sq_off.array + p->sq_entries * sizeof(__u32), PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
   ring_fd, IORING_OFF_SQ_RING);
   sring->head = ptr + p->sq_off.head;
   sring->tail = ptr + p->sq_off.tail;
   sring->ring_mask = ptr + p->sq_off.ring_mask;
   sring->ring_entries = ptr + p->sq_off.ring_entries;
   sring->flags = ptr + p->sq_off.flags;
   sring->dropped = ptr + p->sq_off.dropped;
   sring->array = ptr + p->sq_off.array;
   return sring;
}

io_uring_enter

1
2
3
4
5
6

int io_uring_enter(
   unsigned int fd, // io_uring_setup 返回的那个 fd
   unsigned int to_submit, // tells the kernel that there are up to that amount of sqes ready to be consumed and submitted
   unsigned int min_complete, // asks the kernel to wait for completion of that amount of requests.
   unsigned int flags, 
   sigset_t sig);

可以发现，这个 syscall 可以同时 submit 和 wait for completion，这个也对应了本文作者之前提到的对 aio 的批评之一。

flags 中有一个参数，设置它，则内核会 actively wait for min_complete events to be available。简单来说，如果希望 wait for completion，则必须设置这个 flag。

1

#define IORING_ENTER_GETEVENTS (1U << 0)

5.1 SQE ORDERING

这一节主要讲了如何实现 fsync/fdatasync。

因为之前提到 SQ 和 CQ 是完全独立的，所以这样的机制需要额外的设计。并且因为写入是乱序的，所以我们在乎的是确定所有的写入已经完成。

io_uring 的机制是，支持 draining the submission side queue，直到之前的 completion 事件都已经结束。在这之前，application 会将后续写入入队。

通过 IOSQE_IO_DRAIN 这个 flag 来实现这个特性，它会 stall 住整个 SQ。因此，application 可以考虑使用多个 io_uring context，来保证不相关的写是并行的。

io_uring supports draining the submission side queue until all previous completions have finished. This allows the application queue the above mentioned sync operation and know that it will not start before all previous commandshave completed.

5.2 LINKED SQES

所有连续的指定了 IOSQE_IO_LINK 的 io 请求会被串联起来执行，这些请求一定是按照顺序执行的。但是它们和没有指定 IOSQE_IO_LINK 这个 flag 的请求之间的关系是不确定的。

5.3 TIMEOUT COMMANDS

6.0 Memory ordering

在 并发编程重要概念及比较 中，我们知道 memory order 主要是考虑读-写和写-写问题，如下所示：

read_barrier(): Ensure previous writes are visible before doing subsequent memory reads.
write_barrier(): Order this write after previous writes.

我们也知道，不同的 CPU 架构的乱序执行逻辑是不一样的，所以这里只是讨论概念。

考虑用户侧写入一个 seq，并且通知 kernel 可以去消费了。这就包含了两个过程：

• 填写 sqe 中的字段，并且将 sqe index 写入 SQ ring array
• 更新 SQ ring 队列的 tail

这个操作可以简化成下面的伪代码，每一行代表一个内存操作。如果没有合适的 memory order，CPU 是有理由进行乱序执行的。也就是说，无法保证 write 7 是在最后执行的。

1
2
3
4
5
6
7

1: sqe→opcode = IORING_OP_READV;
2: sqe→fd = fd;
3: sqe→off = 0;
4: sqe→addr = &iovec;
5: sqe→len = 1;
6: sqe→user_data = some_value;
7: sqring→tail = sqring→tail + 1;

所以，需要添加如下的 write barrier

1
2
3
4
5
6
7
8
9

1: sqe→opcode = IORING_OP_READV;
2: sqe→fd = fd;
3: sqe→off = 0;
4: sqe→addr = &iovec;
5: sqe→len = 1;
6: sqe→user_data = some_value;
 write_barrier(); /* ensure previous writes are seen before tail write */
7: sqring→tail = sqring→tail + 1;
 write_barrier(); /* ensure tail write is seen */

7.0 liburing library

通过这个库，可以：

• 不需要写一堆 boiler plate code
• 不需要考虑 memory ordering 的问题
• 不需要考虑自己维护 ring buffer 的问题

7.1 LIBURING IO_URING SETUP

8.0 Advanced use cases and features

8.1 FIXED FILES AND BUFFERS

8.2 POLLED IO

8.3 KERNEL SIDE POLLING

9.0 Performance

Reference

• https://man7.org/linux/man-pages/man2/io_submit.2.html

• LLM 的基础原理
• KVCache

Attention 机制

NLP 对 token 序列 X 的三种编码方式：

• RNN
  RNN 是递归的结构，所以只能串行计算。

  1	y_t = f(y_{t-1}, x_t)

• CNN
  CNN 能够并行计算，但是因为引入了窗口，所以只能看到局部信息。

  1	y_t = f(x_{t-1}, x_t, x_{t+1})

• Attention

Q、K、V

从定义上看，对于 token 流

1

x1, x2, x3, ... xn

每个 xi 通过三组线性变换生成：

1
2
3

Qi = xi * Wq
Ki = xi * Wk
Vi = xi * Wv

考虑下面的句子

1

The animal didn’t cross the street because it was too tired.

句子中的每一个 token，都有一个自己的 Q。用 Wq 可以提取出这个 Q，如下：

• animal → 它在问：后面有没有补充信息？
• because → 它在问：因果关系是什么？
• it → 它在问：我指的是谁？
• tired → 它在问：谁在 tired？

对于 K，则告诉了这个 token 可以回答什么样的 Q：

• animal → 我是一个名词、可能是指代目标
• street → 我是一个地点名词
• because → 我是因果连接词
• tired → 我是状态形容词
• cross → 我是动作

对于 V，承载了语义信息的本体：

• animal → 动物这个实体的语义
• street → 街道的概念
• tired → 疲劳的状态语义
• cross → 穿越动作

Self-Attention

Self-Attention 指的是 Q、K、V 都来自同一组 token 的 attention。即

1
2
3

X → Q = XWq
X → K = XWk
X → V = XWv

然后

1

Attention(Q, K, V)

为什么叫 Self？

• 不是去外部文档查
• 不是去另一段文本查
• 而是在自己这段序列内部相互对齐

对应的是 Cross-Attention：

• Q 来自 Decoder
• K/V 来自 Encoder

容易发现，Cross-Attention 更适合翻译或者对齐另一段文本。而 Self-Attention 更适合理解一句话内部关系。

Multi-Head Attention

如果一个 token 同时想问多种不同类型的问题怎么办？引入多组问题呗。所以上面的三个矩阵会变成三组矩阵。

1
2
3
4

Wq¹ Wk¹ Wv¹
Wq² Wk² Wv²
Wq³ Wk³ Wv³
...

还是对上面的例子而言

对 it 这个 token：

• Head1 问“我指代谁？”，会关注 animal（指代）
• Head2 问“是否有因果关系？”，会关注 because（因果）
• Head3 问“我与哪个动词相关？”，会关注 cross（动作）

KVCache

Why

Token 是模型处理文本的最小离散单位。所以 LLM 并不是直接处理文字，而是直接处理 token。Token 是通过分词器从文本切出来的子串单位。

1

"Hello world" → [15496, 2159]

但是

1
2

"refund" = 1 token
"refunding" = ["refund", "ing"]

不同的模型能够接受不同的上下文长度，因此，它们的 KVCache 也要更大：

• GPT-3.5 4k tokens
• GPT-4 8k / 32k
• Claude 100k

那么 token 是不是特指用户 prompt输入的 token 或者模型输出的 token 呢？其实根据下面的自回归生成，这两个是一个东西。

1

prompt1 → prompt2 → prompt3 → output1 → output2 ...

自回归生成:模型按顺序生成 token，每个 token 都只依赖之前已经生成的 token。
例如，下面的 token 序列中，x1 到 x3 是用户的 prompt 输入

1

x1 → x2 → x3 → x4 → ... → xT

则 xT 生成的方式是

1

P(x_t | x_1, x_2, ..., x_{T-1})

由此可见，自回归生成导致推理是串行的。为什么要自回归生成呢？原因比较深入，可以理解为：

• 语言本质是序列，唯一通用可行的分解方式就是 chain rule
• 自回归训练极其稳定
  输入是前缀，目标是预测下一个 token，loss 是交叉熵。不需要强化学习。
• 从历史演化角度来看，n-gram、RNN、LSTM 等都是自回归的

因为自回归生成，所以导致了 KVCache 的出现。KVCache 把 O(n²) 变成 O(n)。

KVCache 具有如下的形式：

1

KVCache[layer][token_index] = (K, V)

• layer 是 Transformer 架构的层
  现在的 LLM 大都是 Decoder only 的架构，所以这里的层如下所示。

  1 2 3 4 5 6 7 8 9 10 11 12 13

  Input tokens ↓ Embedding ↓ Decoder Block 1 ↓ Decoder Block 2 ↓ ... ↓ Decoder Block N ↓ LM Head

  不同层的 schema 都不同：

  • 第一层：按字形索引
  • 中间层：按语法索引
  • 高层：按语义索引

  每一层内部包含：

  • Masked Self-Attention
    让每个 token 从历史 token 中选择性地读取信息。
    当前 token 只能看到自己和之前的 token，不能看到未来的 token。
  • FFN
    这里就是前馈神经网络，目的是在单个 token 维度上做语义升维和重映射。可以看成是在理解输入的 token。
  • Residual / Norm

• token_index 表示这是第几个 token
  因为 attention 在第 t 步需要：当前 token 的 Q、对比所有历史 token 的 K、加权读取所有历史 token 的 V。所以这些 K 和 V 需要按照 token_index 来存储。

• K 和 V
  K 是我提供什么信息给别人关注。
  V 是别人关注我时能读到什么内容。

• 为什么不需要缓存 Q？
  因为 Q 只在当前步骤被使用。
  在第 t 步，会用 Q_t 去访问 K_{0..t-1}, V_{0..t-1}。但是在未来，不会再去访问 Q_t 了。

如果没有 KVCache，每生成一个新 token 需要重新计算所有历史 token 的 K/V 复杂度是 O(n²)

相关场景

• 训练 infra
  分布式训练、参数同步、checkpoint、通信优化
  DeepSpeed, Megatron-LM, FSDP, NCCL, ZeRO
• 推理 infra
  模型加载、KV Cache 管理、动态批处理、并发调度
  vLLM, TensorRT-LLM, TGI, Ray Serve
• 模型存储与加载
  权重分片、lazy loading、权重格式
  Safetensors, GGUF, Tensor Parallel
• 向量检索
  向量数据库、索引结构、量化 FAISS, Milvus, ScaNN, HNSW, IVF
• 资源编排与调度
  相比传统 k8s 多了 GPU 调度、混部、弹性伸缩。
  相关技术：K8S, Ray, RunPod, vGPU
• 数据管线与特征存储
  数据清洗、分片、版本控制
  Petastorm, Delta Lake, Feature Store

Reference

• https://zh.d2l.ai/chapter_attention-mechanisms/attention-cues.html
• https://transformers.run/c1/attention/
• https://zhuanlan.zhihu.com/p/338817680

如果要在不可变数据结构上进行修改，就需要 clone 一份出来。因此：

• 对于一些较大的结构，希望能够尽量复用
• 如果此时只有一份引用，则可以直接获取 mut 引用就地修改

所以有了 Persistent data structures 的概念：

• 每一次修改该结构，都会保留之前的版本
• 历史的版本可以被查询
• 如果历史版本的数据也支持修改，则称为 Full persistence，否则称为 Partial persistence

实现方案

Copy on Write

用一个数组存放所有的历史版本，非常 bruteforce。

Fat node

为每一个 field 维护历史记录。例如

1
2
3
4
5

struct Node {
    int value;
    Node* left;
    Node* right;
}

会变成

1
2
3
4
5

struct FatNode {
    vector<Pair<version, value>> value_history;
    vector<Pair<version, Node*>> left_history;
    vector<Pair<version, Node*>> right_history;
}

查询的过程就有点像是 MVCC 了。给定一个 version，去 lower_bound 找到最大的小于 version 的修改。

容易看到，Fat node 不支持 Full persistence。

Split

Fat Node 不能无限制增长，否则：

• 历史太长
• 查询复杂度上升
• 节点缓存局部性变差

因此，需要将节点 split 为两个节点：

• 新节点记录最新版本的值
• 老节点保留早期历史
• 结构中指向该节点的指针，也在相应版本中被更新为指向新的节点

Path copying

常见的结构实现

List

Vec

Reference

• https://github.com/orium/rpds

read、write 接口

从普通文件 read，涉及两次复制：

• 从磁盘通过 DMA 读到内核的 page cache
  这里的 page cache 机制也是一种 kernel buffer，但专门提供给磁盘文件的。
• 从内核的 page cache 复制到 user buffer

从套接口读数据：

• 从网卡通过 DMA 直接写入 kernel buffer
• 从 kernel buffer 复制到 user buffer

注意，在使用 DMA 之前，磁盘读出来的数据会放到一个寄存器里面，然后通过中断通知 CPU 把数据写到临时的内存中攒批，最后写到 page cache 中。但是该方式性能太差，早已经淘汰了。

读数据过程：

• 调用 read() 函数陷入内核，第一次 context switch
• DMA 控制器将数据从磁盘拷贝到 kernel buffer，这是第一次 DMA 拷贝
• CPU 将数据从 kernel buffer 复制到 user buffer，这是第一次 CPU 拷贝
• CPU 完成拷贝之后，read() 函数返回到用户态，第二次 context switch

写过程类似。

mmap

把 kernel space 的页映射到 user space，所以可以避免从 kernel space 到 user space 的一次复制。
关于 mmap 可以见 内存领域知识。

sendfile

原始 sendfile

sendfile 将数据从磁盘读到内核的 page cache，然后将 page cache 复制到 socket 的 buffer 中。

它的好处是减少了 syscall 的次数。将 read + write 或者 mmap + write 打包了。
但是，仍然需要 2 次 DMA 拷贝和 1 次 CPU 拷贝。

sendfile + DMA 优化

将从 page cache 到 socket buffer 的那一次 CPU 拷贝去掉了。DMA 可以直接从 page cache 拷贝数据到网卡里面。

splice

限制是 fd_in 和 fd_out 中，至少有一个是 pipe：

• 如果 fd_in 是 pipe，那么 off_in 必须是 NULL
• 如果 fd_in 不是 pipe，且 off_in 是 NULL，那么 bytes are read from fd_in starting from the file offset, and the file offset is adjusted appropriately.
• 如果 fd_in 不是 pipe，且 off_in 不是 NULL，off_in must point to a buffer which specifies the starting offset from which bytes will be read from fd_in; in this case, the file offset of fd_in is not changed, and the offset pointed to by off_in is adjusted appropriately instead.

这里解释一下什么是 linux 中的管道：

• 匿名管道（anonymous pipe）
  由父进程创建，用在具有亲缘关系的进程之间通信。
  通过 pipe() 系统调用创建，返回一对文件描述符：一个用于写，一个用于读。
  只存在于内存中，它不是一个磁盘上的文件，不能用 ls 查看，也没有 inode 号。
• 命名管道（named pipe，也叫 FIFO）
  具有名字的管道，可以存在于文件系统中，有路径。文件类型是 p，代表 pipe。
  通过 mkfifo 命令或者 mkfifo() 系统调用创建。
  可以实现非亲缘进程之间的通信。

所有的匿名管道都支持 splice，通常借助匿名管道来实现 zero copy。此时，pipefd 就起到了中转管道的作用，它连接了两个彼此之间不支持零拷贝的 fd。我觉得是一个比较有意思的设计，通过匿名管道的中介，减少了不同 fd 之间实现相互 zero copy 的复杂度。

1
2

splice(file_fd, NULL, pipefd[1], NULL, len, 0);
splice(pipefd[0], NULL, socket_fd, NULL, len, 0);

一些命名管道也支持 splice，但是可能只是可读写，非零拷贝中转。

1
2
3

ssize_t splice(int fd_in, off_t *_Nullable off_in,
              int fd_out, off_t *_Nullable off_out,
              size_t size, unsigned int flags);

Flag 如下：

• SPLICE_F_MOVE
  Attempt to move pages instead of copying. 这里的 move 指的是内核页缓存中的物理页面的引用在 fd 之间进行转移。而不需要读出、复制到 user space、写入这样的流程了。
  注意，这个 flag 只是一个 hint。如果内核无法移动，则还是需要复制。如果 pipe buffer 不指向整个页面。
  The initial implementation of this flag was buggy: therefore starting in Linux 2.6.21 it is a no-op (but is still permitted in a splice() call); in the future, a correct implementation may be restored.
• SPLICE_F_NONBLOCK
  Do not block on I/O. This makes the splice pipe operations nonblocking, but splice() may nevertheless block because the file descriptors that are spliced to/from may block (unless they have the O_NONBLOCK flag set).
• SPLICE_F_MORE
  More data will be coming in a subsequent splice. This is a helpful hint when the fd_out refers to a socket (see also
  the description of MSG_MORE in send(2), and the description of TCP_CORK in tcp(7)).
• SPLICE_F_GIFT
  Unused for splice(); see vmsplice(2).

vmsplice

splice 主要是服务内核空间中的数据传输，原因是指定的都是 fd 或者 pipe，并不包含用户空间中内存的信息。
而 vmsplice 主要服务用户空间和管道之间的数据读写，它们都能实现零拷贝。

1
2
3
4
5

#define _GNU_SOURCE         /* See feature_test_macros(7) */
#include <fcntl.h>

ssize_t vmsplice(int fd, const struct iovec *iov,
                size_t nr_segs, unsigned int flags);

iov 是一个长度为 nr_segs 的数组，表示用户内存中的多段可能不连续的 buffer。

参数：

• SPLICE_F_MOVE
  Unused for vmsplice(); see splice(2).

• SPLICE_F_NONBLOCK
  Do not block on I/O; see splice(2) for further details.

• SPLICE_F_MORE
  Currently has no effect for vmsplice(), but may be implemented in the future; see splice(2).

• SPLICE_F_GIFT
  The user pages are a gift to the kernel.
  表示用户程序不会修改这段 buffer，否则，page cache 和磁盘中的数据就可能不一致。
  将 pages gifting 给内核意味着后面的 splice SPLICE_F_MOVE 能够成功移动 pages。如果不指定，则后续的 splice SPLICE_F_MOVE 必须复制。
  数据必须要 page aligned。我理解这里指的是：

  • iovec[i].iov_base 需要对齐到页
  • iov_len 需要是页大小的整数倍

  如果不满足，则退化到 copy 的行为。

Reference

• https://man7.org/linux/man-pages/man2/splice.2.html
• https://man7.org/linux/man-pages/man2/pipe.2.html

One of the most notable aspects of this project is that it has been developed alongside the rapid evolution of AI agents, which led us to encounter many pitfalls when practicing vibe coding.

About Vide Coding: The benefits and the pitfalls

Pitfalls of Vibe Coding

In early 2025, at the initial stage of our project, one of our core contributors quickly prototyped a demo using Cursor, covering multiple modules such as the read scheduler, index writer, and meta service.

Traces of this early implementation can still be found in the following pull requests:

• https://github.com/pingcap-inc/tici/pull/48
• https://github.com/pingcap-inc/tici/pull/673

Make AI agent more focused

Why focused attention matters

Agents have a limited attention budget. When a prompt blends background, implementation details, and review notes, attention is spread thin and the model drifts. Treating the prompt as code and slicing the work into sub goals keeps the highest-signal spec in focus, which improves determinism, reduces requirement misses, and lowers evaluation cost.

How to draw attention of AI agent

We can treat prompt as code. This is not a new idea in the industry, but many teams apply it unevenly. A common practice is to store prompts as markdown or templates under version control, so they can be reviewed, diffed, and rolled back like any other artifact. Some teams go further and build a “prompt registry” or config service to version prompts outside the codebase, and pair it with evaluation suites that act like unit tests for prompts (golden outputs, A/B runs, regression checks). Others embed prompts directly in application code as constants, which makes deployment easy but tends to hide intent and lose reviewability. The shared direction is clear: treat prompts as first-class assets with explicit structure, reviews, and tests.

I wrote a PR, https://github.com/pingcap-inc/tici/pull/692/files, where the core file is prompts/0001-gc-cdc.md. That file is the prompt itself, and it is committed with the PR, so anyone can start a session by loading the same prompt. It becomes versioned, diffable, and reviewable like real code, and the team no longer depends on a hidden chat history. Also, we can divide the whole goal into several sub goals and let AI agents to implement different sub goals sequentially or in parallel. And we don’t need to tell the AI the context everytime.

I think this can effectively make the AI agent more focused on what it needs to do, so as to generate bettwer codes with less resources.

Reviewers can write feedback directly in the Reviews section of the prompt doc, and I can pull that back into the next round of vibe. This workflow makes context length much less of a concern because the prompt is the canonical spec. A minimal shape looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# Goal

...

## Sub goal 1

In this sub goal, you need to ...

### Programming Style

### Musts

### Tests

## Reviews

Rust as the language of “Vide Coding Era”

As Rust becomes increasingly adopted in the “vibe coding era”, it does offer stronger guarantees against concurrency and memory errors. However, it is still too early to say that Rust is THE ONE.

Such an AT-Agent native language will likely consist of at least three distinct sub-languages:

• One for expressing intent
  This is the most critical language, because developers need a more efficient way to understand what AI agents have actually done.
• One for validating correctness
  The language corresponds to the intent language, and is designed to describe test workflows more efficiently. Developers can fine-tune this part of the code to guide AI agents to generate correct code for corner cases.
• One for concrete implementation
  This language is responsible for concrete implementation. Many AI agents, such as Codex, can already handle this layer well, as they rarely make trivial mistakes. Developers do not need to review this part of the code frequently, as other AI agents can handle the review instead.

Only with this separation can we truly balance readability, robustness, and long-term maintainability. Furthermore, many of the current libraries can be rewritten to be more friendly to AI agent.

Use Skills

I introduced several SKILLs into our new project. For example, ManualTest enables AI agents to execute manual test cases automatically.

Implement tests

Hierarchy of tests

The problem

Because each TiDB component is maintained in a separate repository, breaking changes in one component require coordinated adaptations across multiple repositories. Unfortunately, such adaptations cannot be performed atomically and are often non-trivial. While compilation flags or configuration options can sometimes be used to temporarily disable new features, this strategy is not always applicable. In particular, interface changes such as FFI definitions may break compatibility immediately.

In our project, an end-to-end (e2e) test starts a full cluster and asserts it from a client’s perspective, which in our case means sending SQL queries to the database service. Some of these tests are included in our CI pipeline. However, CI-based e2e tests cannot reliably detect adaptation issues. This creates a classic catch-22: resolving an adaptation problem requires updating all related components, yet the e2e tests cannot pass while you are still fixing the first component. As a result, most e2e tests are deferred to what we call the “daily tests”.

Nevertheless, we still need a subset of e2e tests in the CI pipeline. Although these tests may occasionally produce false positives due to compilation or adaptation issues, they provide valuable systematic checks to ensure that a new commit in one component does not break existing rules or behaviors. Deferring such checks to daily tests would be disastrous, as it makes bugs significantly harder to triage. When issues accumulate over time, the project can easily fall into a “bug jail,” where fixing new problems becomes increasingly expensive.

It is also worth noting that integration tests cannot practically detect all logical bugs. In many cases, module owners write integration tests mainly to verify that their own modules work with others, while overlooking the impact their changes may have on the system as a whole. This issue becomes even more critical when AI agents are used to refactor our code, as we need safeguards to ensure that unexpected behavior does not compromise the foundation of the project.

During the development and PoC stage of our project, several critical issues occurred because the tests were not correctly implemented, including:

• Module A uses the API of Module B in a wrong way. Neither is there integration test of Module A, nor its scene is covered in the e2e test.
• Module C fails to verify a corner case, which is later caught by my embedded e2e test (introduced later). This kind of error is easy to be ignored, because it passes all tests except one. However, that single test protects our system from an availability failure caused by a deadlock in Module C.
• Another component changed its convention for constructing a field in an RPC request without informing us, which caused the system to malfunction at the SQL layer and made the issue difficult to investigate. This problem was also detected by my embedded e2e test.

The layers of tests

We can organize the tests for Component A into several layers. Each layer targets specific categories of bugs, and issues detected at lower layers should not propagate to higher layers.

• Daily regression: full system tests for cross-component compatibility only. However, no bugs originating from Component A itself should reach this level. We must proactively investigate daily test failures to avoid falling into a bug jail.
• E2e tests with real components: We may occasionally allow skipping tests at this layer, because cross-component checks can fail due to upstream changes, as discussed earlier. However, bugs that originate within Component A itself must not propagate to this level.
• Integration tests:
  • Embedded e2e: at the component boundary, using mocked RPC/status/FFI calls; required when interface semantics change; validates external behavior and isolates compatibility issues.
  • Module integration: per-module behavior with or without mocks; required for new features or refactors; may need test framework enhancements.
• Unit tests: unit or local integration tests within a single module; most of these can be handled by AI agents.

The embeded e2e test

This idea is based on the observation that a component’s behavior is defined by how it communicates with other components, through RPC, FFI, shared memory, and similar mechanisms.

Therefore, mocking these communications in integration tests provides the following benefits:

• We don’t need to start a full cluster, so we won’t face the adaption problem.
• If an adaptation issue occurs, it can be easily reproduced at this level. This not only simplifies the debugging process, but also increases our confidence in the code.
• This test treats our program as a black box, which makes it easier to implement because we do not need to understand how each module is implemented. These tests are expected to remain stable unless the interfaces or communication frameworks change.

Tests as the Backbone of Vibe Coding

In a Vibe Coding workflow, tests become the primary communication channel between intention and code. Among all types of tests, the embedded end-to-end (e2e) tests play a more and more important role.

Unlike unit tests, which specify local behavior, or integration tests, which usually verify a limited subsystem, my embedded e2e tests define system-level behavioral contracts. They describe what the system should do rather than how it should do it. This makes them naturally aligned with Test-Driven Development (TDD): they serve as executable specifications that drive the implementation.

Systematic choices

Thread or coroutine?

Benefits of using tokio:

• Smaller memory cost, so we can create more coroutines.
• Context switch is faster because there is no syscall.

Pitfalls of using tokio:

• We cannot control the scheduling strategy of tokio’s runtime. For example, we cannot assign a priority to a specific task, nor can we limit the CPU quota of a particular class of tasks.
• Switching to async code is often painful, as even the simplest function may become suspendable due to the use of tokio::sync locks.
• It is hard to investigate deadlock / starvation problems.
• Hard to use itertools. futures::stream can help, but it generates complex types.

Use seperated Runtime for different task pool?

Runtime can only be created outside the “async context” of tokio. So if we need to use tuned Runtimes, we have to create them in advance. This involves lots of refactors.

Propagate the panic outward

We must pay attention to panics inside the actor’s message loop: the handler, whether a thread or a coroutine, will only surface the panic when it is eventually joined, by which time the failure may have gone unnoticed for too long. What I recommend is to:

• Employ the panic_hook to capture the exact scene where things go wrong.

  1 2 3 4

  panic::set_hook(Box::new(|info| { eprintln!("Task panicked: {}", info); println!("Task panicked: {}", info); }));

• Eliminate unwraps and expects

  1 2	#![cfg_attr(not(test), deny(clippy::unwrap_used))] #![cfg_attr(not(test), deny(clippy::expect_used))]

Shared Memory or Actor model?

If we use the coroutine runtime, we may need to decide how to handle race conditions.

Why are “deadlock”s so hard to diagnose when using coroutines?

1. There is neither a wait-for graph in the coroutine runtime nor one in the OS
   await does not block a thread, so we can’t find anything with gdb/strace/perf.
   Meanwhile, these “deadlocks” are hard to be detected because they appears that there is no CPU, no blocking thread, and the program is in a “vegetative state”.
   Coroutine frameworks like tokio provides some o11y tools, however, they are hard to use, and have performance overhead.
2. No actual “deadlock”
   These stalls are mostly “waiting for a train at a bus stop” errors. For example, we may read from a channel which will never be written, which is an easy mistake when we bail on an error without calling .send() first.
   So we recommend to send a Result<T>, and implement a Drop trait that automatically sends Err(Error::DropWithoutReport) as a last-minute remedy.
3. No actual “stack”
   Coroutines don’t carry a real stack. When they hit an await they yield a continuation, and that continuation may be resumed on the same or a different thread.

tokio::RwLock or std::sync::Mutex?

There is a public belief that we have to always use tokio locks in asynchronous code. However, according to the reference of tokio, it is ok and better to use synchronous locks such as std::sync::Mutex or parking_lot::Mutex.

I’d like to refer to these cases as “atomic access structures”, because they all follow the following patten:

1
2
3
4
5
6
7
8
9

struct Wrapped {
    inner: Mutex<String>,
}

impl Wrapped {
    pub fn change_inner(&self, s: String) {
        self.inner.lock().expect("") = s;
    }
}

The key point of this code is to avoid directly exposing the lock itself: we must not allow external callers to access it, and we must atomically release the lock after mutating the protected value. The underlying rationale is that we must not allow a coroutine to “sleep” while holding the lock, as this guarantees that no deadlocks will occur, because:

• If a coroutine holds the lock, it will not “sleep”, because the code change_inner is structured to avoid calling .await while the lock is held. Moreover, the executor thread will not sleep either, since it is not waiting on any condition.
• If a coroutine does not hold the lock, it can eventually acquire it, because the current holder will release the lock promptly. And of course, the lock is released before any suspension point.

For synchronous lock:

• std::sync::Mutex supports poisoning. If a thread panics while holding the lock, future lock() calls return a PoisonError, forcing the caller to acknowledge that the protected state may be inconsistent. However, in most cases such an error can’t be processed, it will eventually lead to a panic, which is not elegant. There are also some other choices, simply accepting the risk is similar with parking_lot::Mutex, and resetting the state is not hazard if there are other threads waiting for this lock.
• parking_lot::Mutex is faster and smaller in many workloads (especially uncontended or lightly contended), but it does not poison. This often turns a hard failure into a latent, harder-to-debug corruption.

The lack of poisoning is exactly why parking_lot::Mutex can be unsafe at the logic level. If a panic happens after partially mutating the protected value, the invariant is already broken. So, unless you can guarantee panic-free critical sections or have a clear recovery path, prefer the standard mutex to make invariant breaks visible. I think the best practice is to abort if any thread panics, which can be easily done with panic hooks.

Implementing an “incomplete” actor mode

In the traditional actor model, each actor node encapsulates its own private data. However, this model is difficult to implement because:

• To rebalance data across nodes, we must introduce new message types and corresponding handlers.
• Inspecting the internal state of actor nodes is difficult.

So, as a simpler alternative, we can:

• Use a concurrent hash map to store all data, with each actor node mutating a portion of the map.
• Allow other components to read or inspect entries in the concurrent hash map. Such inspectors can not mutate the entries, and their accessment must be atomic.

A preferred candidate for the hash map is DashMap. Although this structure frees us from requiring &mut self, most of its methods return a Ref or RefMut that holds a lock guard, so incorrect usage can lead to deadlocks. The following codes shows a simple example.

1
2
3
4
5
6
7
8
9
10
11
12
13

#[test]
fn test_dashmap() {
    let map = DashMap::new();
    map.insert(1, 1);
    map.insert(2, 2);

    for entry in map.iter() {
        println!("{} -> {}", entry.key(), entry.value());
        map.insert(3, 3);
    }

    println!("test end");
}

There is a simple yet effective way to detect potential issues in our code: use #[tokio::test] instead of #[tokio::test(flavor = "multi_thread")]. With the single-threaded runtime, the program will fail immediately if a coroutine “sleeps” while holding a lock.

The linking problem

FFI

TODO

How to support TLS?

TODO

Online config change

There are some ways to update configs without restarting the program:

• For every actor, introduce a new UpdateConfig event, and handle it in the message loop.
• Using arc_swap.

I don’t think the service itself should persist the updated configuration to the config file. Instead, this should be handled by the operator.

Day 1

主要修正了下反手动作。

这里，我最重要的是不要架肘。打的时候，可以用左手稍微按着一点左边的大臂。
然后，乒乓球反手是小臂带动大臂，大臂基本上不用特别发力，而是让小臂画 1/4 的圆弧。
在打完之后，需要还原。击球时，击球点不要太到台内，仿佛把整个手都要伸出去一般。
击球的是高点期。注意，不要急，而是等球到位之后再打，实际上质量更好。
当球落点朝着左边或者右边偏斜的时候，可以考虑靠只移动上半身来接。
作为初学者，不需要手腕有特别大的扭转。

-> 初学者，可以采用下蹲马步，然后再站起来这样。但是最终，是要一直处于一种扎马步的状态，主要是前脚掌着地。然后用一些垫步还是啥的完成重心转换。

Day 2

主要纠正了下正手动作。

我正手有几点问题：

• 撅手腕，教练说撅着手腕可能是因为击打点太靠前，以至于要“等球：
• 大臂架着
• 大臂还喜欢架着往后拉，实际上应该是转腰，而不是动大臂
• 握拍应该虎口直接对着拍子的“侧棱”，类似于羽毛球一样，我可能会喜欢转一点

Day 3

继续是正手和反手的练习，下雨，只有 1.5h。

提到了一些细节：

• 反手可以尝试蹲起，然后站立这种击打方式

录制了一些视频，视频中可以发现，还是喜欢撅着手腕。

Day 4

继续是正手和反手的练习，有事，只有 1.5h。

Aug 21

Sept 12

Sept 19

因为重新看了下医生，说暂时不要运动，因此这次就练了下搓球。

搓球的话主要几点：

• 腿要伸进去
• 重心一定要压低压低！可以感受到脸要贴着桌子的感觉
• 击球点要低，基本上是二跳要落下，就要完蛋的那个时候搓。但尽管如此，人是要先上去的，所以这里有一个停顿

Sept 26

本周停止

Oct 22

Oct 30

• 握拍得贴着虎口。因为虎口很大，所以是得靠大拇指一侧，而不是食指一侧
• 搓球的时候，中心前压，不是说要驼背，而是腹部发力
• 打球的时候，可以尝试只用前脚掌，把重心放到前脚掌上
• 摆速的时候，手不要拉
• 搓球的时候，中心要低，但不要趴桌上

Nov 13

正手虽然动作大，但是击球点靠后，所以空中时间长。

搓球亮板子是为了接触面积大。

Nov 21

• 搓球的时候，不要靠大臂往前戳。而是要以肘为轴心，小臂往前，大臂是不需要往前伸的

Dec 11

正手攻球打球有几点：

• 上旋球，如果弧线比较低，也不需要提，直接打过去就行
• 攻球的时候，不仅要注意手不要翘，不要拉手。手腕最好跟搓球一样，能拱一点起来。整体来讲，就是要接触面积大。

反手攻球，发现有时候会打下网，原因还是我手腕没有偏拱，而是有点把手翘起来的感觉。我在微信里面备注了个图，可以参考下。

另外，进一步看了正手搓球：

• 重心还是要低，这里强调了一下，肘部也要低。我打球的时候，可能是提着肘，然后手在下面。其实应该肘和手都在下面。
• 可以想象，准备姿势，重心压低。这个时候，手臂是很贴近台面的。所以，正手搓球的时候，只需要把手臂打横就行了。
• 搓球也需要往前送，正手搓球不要往自己身体收前臂，而是往前送。
• 其实搓球搓起来，球不太容易很贴网的。

Jan 7

中间放假缺了一节课，另外和 fzh 又打了几场球，感觉正手搓球有点差了。主要体现在：

• 伸手太靠近身体
• 身体的发力太多了，手上的动作少了
• 小臂不要翘上去，搞得像一个 V 字一样，还是要放下来一点

在攻球方面，感觉膝盖好了不少。

然后初步学习一下反手拉球，感觉我自己的问题是：

• 手肘架太高了，更像拧
• 可能是怕刮到球台，自己退台太多了

这里的一个重点在于：

• 手腕一定要引拍，让球拍对着自己
• 拉球完毕后，手腕应该恢复类似正常的攻球状态，不要往上翘。其实往上翘也是我之前攻球常见的一个错误问题

我理解反手拉球随着你引拍是在身体左边、中间还是右边，动作的大小和幅度不太一样，但是框架是一样的，就是手腕要制造摩擦。

Jan 8 的时候又和 fzh 语音交流了一下。他的意思是反手拉球其实最重要的是能拉到别人搓过来的比较快并且贴身体的球。基本上退台是不会反手拉的。

Jan 30

今天又是只有我一个人。

搓球：

• 正手搓球不要在身体前面，而是要打开手臂，在身体右前方击球，原因是因为要有一致性。这样，站在那个位置，处理方式会有很多，不会给人感觉你就一定是搓球。不过打开手臂之后，还是要往前的，不能往身体方向收手臂。这个刻意注意一下就行。
• 另一种注意的办法是，搓球的时候可以有个停顿。这里的停顿不是说你就把拍子放在那里等球来了，我们肯定是要向着球制造摩擦的。但是就和羽毛球那样，得有一种“定”的感觉。或者可以认为伸手臂和往前搓实际上可以分解为两个动作。

拉球：

• 反手拉球直接跨步调整位置，不需要滑步。这是因为反手的地方就那么一块，滑步的动作太大了。

另外，我觉得拉球我的问题主要是：

• 不要边动边打球。脚步站好的时候，最好重心也调整好，比如该蹲那时候就蹲了，不要一边挥拍一边往下蹲，这样很难瞄准。
• 拍子要在下面，从下往上挥动。
• 拍子不要往上走，往上是通过手腕那个旋转来做的。手臂就是放松，自然展开就行。

Feb 12

学了下劈长。感觉这个很讲究瞬间发力。

• 如果小臂移动太多，那么就容易出界
• 如果手腕移动太多，比如最后往上翘了，那么也容易出界

另外今天体验了一下摆短。我确实可以摆起来，但是是卸力把球托过去的，并没有搓很转，所以没有什么威胁。

今天尝试了下拉球，就是彻底把手放下来，然后就发现有个明显的好处，就是如果我手自然下垂，那么我就没必要很刻意地去内旋我的手腕了，反而更轻松。

D1

这一次从南京直飞大阪。机票照例没有提前多久定，但是两个人往返也才 4k 出头，相当便宜。宾馆就是贵的离谱了。京都的宾馆单人 1.5k，双人接近 4k 感觉简直在抢钱。我先在大阪定了 2 天 700 左右的。然后又订了一天姬路和大阪的。然后最后一天住哪不清楚，大概先这样。

关西机场入国变得麻烦多了，这次虽然没有坐小火车（吉祥航空），但入关排队感觉就花了将近一个小时了。在飞机上被发了入境单要填，我觉得挺麻烦的，现在都是电子化了啊。结果到了入境口发现有 abcd 四个 route，但完全不知道区别是什么。一个国际机场居然没有英文的说明，工作人员也只说日语和简单的英语。Anyway，他有个扫描护照的机器，感觉挺方便的。我用机器扫完，然后就再往前排队等人工。走到一半发现大家还有个 QR code 也不知道是啥，但是这些人扫完 QR 之后又要填一遍纸单子。。。

反正轮到我我就说 I have no QA code but I’ve already finished the note, and I’ve already registered on that machine. 然后那人把我的纸收了就直接贴入境单了，很丝滑很快。这次不去京都，就直接走南海电车了，更便宜。坐到 namba 才 900。

吃完饭，就去附近的 apple 店买个表。现在日本的 apple 店居然不能退税了，只有部分非官方 retailer 可以退税，但是我又不知道哪里靠谱。46mm 的要 3200，国内才 2600。但是因为国内啥啥都没，没快充慢的一批，所以还是买了。总不能为这个专门跑一次 hk 吧。

去 711 给交通卡充值，发现只能用现金。幸亏我带了 15000 jpy 来，本意是上次玩没用掉，这次结果救了命。

晚上出去吃饭回来，发现大阪真的冷，幸亏穿了两件，不然真的冻死。

回来发现日本的窗子真的好隔音，薄薄的平开窗，毫无特点的铝合金，居然这么猛。

D2 京都

因为地铁卡充值要现金感觉不方便，所以我今天就打算不用地铁卡，用 iPhone Wallet 了。这鬼东西又不能用信用卡，我弄了半天才弄了个储蓄卡上去。上地铁又刷坏了，墨迹了半天。到了大阪梅田站，她出不了站，刷了半天不知道怎么就出去了。结果到了 JR 大阪站发现进不去，问工作人员说这个是 osaka subway，我觉得很奇怪，因为 icoca 是通用的，工作人员也说我的 iPhone 是可以的。于是我觉得肯定是被锁了。无论如何，这里可以支付宝买纸票，于是我们就去京都了。

京都的公交车排队排了感觉有半个多小时，后面上了个临时的加班车。这边还不让带行李上公交车，幸亏我们都放在了大阪，就带了个小包。公交车里面非常拥挤，但我们进去的早，所以有个位置。公交车开的特别慢，感觉甚至不如走路。开到清水寺附近感觉花了大概二十多分钟。我们试图在五年阪下车，结果被堵住了，然后司机就不让我们下了。然后后面一个傻逼老外就说 you come here late, you have to follow their rules, it’s not your country 啥的。非常 offensive。

清水寺我们没进去，我对象说没啥意思，我之前去过，感觉也没啥意思，人还特别多。门口的御守他也觉得贼丑。然后我们就顺着三年半二年阪往下走，去找法观寺。我们都已经看到高台寺公园了，发现法观寺走过了，有绕回去找。结果法观寺就是我们来的路上的那个我觉得一般的唐代风格的塔，好像是京都的最老的塔，也不让进去。然后我们又走回到高台寺。

高台寺的垂樱是挺好看的。

高台寺出来很快就到了八阪神社，里面和好吃街一样，我们找了下垂樱在哪里，就去吃那个鳗鱼饭了。

鳗鱼饭吃完出来，就在木屋町那条小路那边拍樱花，感觉比鸭川的樱花好看。

然后又绕回去看了下花见小路，照旧非常无聊。路尽头是什么建仁寺的，大家都没有兴趣看。

然后又走了一大段路去看顶法寺。顶法寺不要钱，里面的樱花很漂亮。还有几个小和尚的雕塑也很有意思。

晚上实在走不动了，就坐了京阪电车，因为阪急还要多走 300m。至于京都 JR，因为坐公交体验太差，完全不考虑了。我们坐的是 18.59 的京阪电车去的大阪。其实以后真的可以坐京阪电车到京都东边，比 JR 方便很多，还便宜。但这次京阪电车属实是个坑货。它终点站在大阪是 yodoyabashi 淀屋桥，但是又有一些车是到一个叫 yodo 淀的地方。然后我就被这个车丢在了 yodo。后面上了个准急的，几乎就是站站乐了，感觉总共花了大概一个多小时才到大阪。

回到大阪，找大阪地铁说明了情况，列车长问我们要不要 refund。我说不要，他就说 OK。然后就解锁了，结果发现之前坐的 namba 的南海的钱居然也没被扣。南海真的血亏啊。

D3 姬路

起来去姬路。这次发现他们电车同一个方向有两个轨道，一边是 local 一边是 express。上车前可以看站台上的屏幕，上车时可以看车的屏幕确认。上车前可以看 Google 或者 Apple 的 map 到达的时间确定自己是不是对应班次的车。上车后也可以听播报。基本上 Rapid、Express 的车都比较推荐，大阪、神户市区的大站基本都停。Limited Express 特急要特价券我没见过。

姬路是个小城市，我们的酒店在车站南边一点。应该是此行中比较大的酒店了。酒店不能提前办理入住，但是可以预先寄存。

姬路站北面正对姬路城，通过一个大道可以直接走过去。大道两侧不少店铺比较出名，我们吃了个咖啡，然后就立即前往姬路城了。

城里面樱花很漂亮，右边走还有个动物园。登城口在左边，要排队，但是队伍很快，等了大概半小时就进去了。买票 +50 yen 就能得到一个旁边的花园的门票。花园里面有个餐厅，我们去的时候已经关门了。姬路城主要就是两块，一个是西之丸庭院，可以脱掉鞋子登上去，类似于一个走廊，有多个城橹。从化妆橹可以下来，据说这个是给城主夫人化妆用的地方。西之丸庭院相比大阪城比较小巧，里面也有不少樱花。

从庭院出来就可以走到天守的口了。然后就是穿过一道道什么 yi 之门、wa 之门、ni 之门，然后走到天守的下面的小庭院内。然后就走过水之 X 门走到大天守里面。大天守有 6 层，第 2 层开始大排长队，人贼多。

D4 神户

神户的酒店在三宫门口，应该是本次我找的最近、最便宜的酒店了，才 500。住宿体验很舒适。

放完东西，去神户动物园。我们应该是顶门到的，进去刷票的时候，我对象把票根掉了，检票员说必须要把票找回来。

在那个破落商店里面有一家后来知道叫 Yellow Submarine 的桌游超市，还挺大的。回来我去问了下有没有那个骰子游戏，他带我去找，然后翻了下，说 sold out 了。我以为附近南京町还有一家，走过去发现那是个别的地方，已经关门了。

D5 奈良 - 大阪

下了奈良站，在 5 号口附近找到一个柜子，600 yen 就可以放两个小箱子和一个包了。不过只接受 100 yen 的硬币，我还要去旁边换。

出去吃了那个口水麻薯，一堆老外在那边拍照。去看了兴福寺，要钱，没意思没进去。兴福寺下来就能看到鹿，鹿很现实，看到我们没买饼就不磕头了。我们到最后也没买，主打白嫖。

旁边的奈良博物馆关门了。

我印象里上次去若草山有个大坡可以坐着休息，但这次去好像就是一些大草坪可以走，有椅子可以坐。大草坪也许是封起来了吧，因为当时看到大草坪上没有人，而且往若草山方向有被拦住。

在大阪这最后一晚住的酒店是最拉胯的。

D6 大阪

• We Ain’t Afraid of No File Fragmentation: Causes and Prevention of Its Performance Impact on Modern Flash SSDs

We Ain’t Afraid of No File Fragmentation: Causes and Prevention of Its Performance Impact on Modern Flash SSDs

https://www.usenix.org/system/files/fast24-jun.pdf

Abstract

The primary cause of the degraded performance is not due to request splitting but stems from a significant increase in die-level collisions.

如果在写连续的 file block 中，有其他的写入过来，那么这些 file block 就不会在连续的 die 上，从而产生 random die allocation。这种情况比如发生在 file overwrite 的时候。

In SSDs, when other writes come between writes of neighboring file blocks, the file blocks are not placed on consecutive dies, resulting in random die allocation. This randomness escalates the chances of die-level collisions, causing deteriorated read performance later. We also reveal that this may happen when a file is overwritten.

Evaluations with commercial SSDs and an SSD emulator indicate that our approach effectively curtails the read performance drop arising from both fragmentation and overwrites, all without the need for defragmentation. Representatively, when a 162 MB SQLite database was fragmented into 10,011 pieces, our approach limited the performance drop to 3.5%, while the conventional system experienced a 40% decline.

Introduction

To prevent performance degradation caused by fragmentation, file systems utilize various techniques [35], such as delayed allocation [23] and preallocation of data blocks [2], to maintain continuity among data blocks.

SSD 中没有磁头的物理移动，所以减少了顺序读和随机读之间的性能 gap。但 [4] 中说，SSD 上读 fragmented 的文件，也有 2-5 倍的性能损失。诸如 [13, 31, 42] 的文件只是认为这些性能损失的原因是 request splitting in the kernel I/O path due to fragmentation。

这篇文章指出 fragmentation 导致的性能损失实际上根因是 die-level collisions。而 die-level collisions 会减少 SSD 内部的并发度。

An SSD’s firmware allocates its flash memory pages in a round-robin manner across the flash memory dies based on the order in which they are written.

所以，如果发生了 fragmentation，那么 the pages storing contiguous file blocks 不能被放置在 contiguous dies 上，而是被分配在任意的 dies 上。

这个论文修改了 nvme 的协议，让 write 命令指定 page-to-die mapping。

With these hints, the page for an appending write is mapped to the die following the die where the previous file block’s page was assigned to. In addition, the page for an overwrite operation to an existing file block, which also disrupts the page-to-die mapping pattern, is mapped to the same die where the original page was located.

Background and Motivation

Old Wisdom on File Fragmentation

In the HDD era, the primary and direct cause of performance degradation from file fragmentation was the seek time between dispersed sectors of the file.

Fragmentation 对读取的影响更大，因为读取必须要等待完成，而写入则可以被 buffer。

Fragmentation 在三个层面影响性能：

• kernel I/O path
  Only a single command is required for the host to instruct the storage device to perform read or write operations on contiguous storage space.
  Thus, when a sequential read occurs for a file, the Linux kernel reads the data block mapping in the file’s inode, and for each contiguous data block region, it creates a bio (block I/O) data structure. This data structure is used to create the corresponding request data structure to be passed to the device driver, which then issues the command for the request to the device.
  Through this process, a single sequential file access may be split into multiple bios and corresponding requests to the storage device, depending on the degree of file fragmentation.
• storage device interface
  This request splitting is known to increase I/O execution time, as it increases the number of data structure creations and calls to underlying functions, including the device driver code.
  Specifically, the frequency of fetching, decoding, translating commands into storage media operations, and queuing media access operations increases. Therefore, file fragmentation also delays the processing time of the storage device controller.
• storage media access

ext4 为了减少 fragment 产生的优化：

• The delayed allocation technique used in the ext4 file system performs data block allocation not at the write system call handling but at the time of page flush.
• In addition, ext4 reserves a predefined window of free data blocks for each file’s inode. These reserved free blocks will be actually allocated to the file for its successive append writes.

defragmentation 的手段：

• 【Sato】Allocates contiguous free blocks to a temporary inode, copies the fragmented file data to the temporary inode, deletes the original file, and renames the temporary inode to the original’s.

File Fragmentation in SSD-Era

很多学者和厂商说 SSD 不受 fragmentation 的影响，defragmentation 反而可能会损害 SSD 的寿命。

SSDs offer significantly higher performance than a single flash memory die (chip) because they operate multiple flash dies in parallel.

NVMe 有 65535 个命令队列，每个队列能 queue 65535 个 commands。总共 65535 的平方，可以说非常大了。

Specifically, NVMe SSDs offer 65,535 command queues, each capable of queueing 65,536 commands.

Even when fragmentation leads to smaller request sizes that cannot fully utilize die-level parallelism, smaller flash operations in the command queues can still be processed out-of-order, allowing most dies to be fully utilized.

因此，很多学者认为 kernel I/O path 和 storage device interface 中的 request splitting 是影响性能的关键。

Internals of Modern Flash SSDs

a die can only process one request at a time.

FTL 会将需要写入的 page 存储到尽可能多的 die 中。

To prevent die-level collisions for read operations, the flash translation layer (FTL) of an SSD’s firmware must perform physical page allocation in a manner that distributes the physical pages storing contiguous logical pages across as many dies as possible.

所以，是 rr 地选择 die，而不是一股脑全写到一个 die 里面。

For this purpose, the FTL of most modern SSDs selects a die in a round-robin manner when allocating a flash page for processing an incoming page write request.

Additionally, modern FTLs perform the valid page copy within the die where the page resides during the garbage collection (GC) process if the die has a sufficient number of free pages.

For example, in Fig. 2, File A is evenly distributed across four dies since its four pages were written without interference. Thus, a sequential read of File A will be performed simultaneously on these four dies, resulting in a bandwidth of up to four times the flash die performance.

In contrast, assume that the writes to File B and File C were interleaved. As the die for storing a logical page is assigned in a round-robin manner according to the order of writes performed within the SSD, both the third and last pages of File B ended up being allocated to Die 3. As a result, the time to read File B is twice as long as that for reading an ideally-placed file of the same size, such as File A.

常见变位

• aller：去
  • je vais
  • tu vas
  • il/elle va
  • nous allons
  • vous allez
  • ils/elles vont
• avoir：有
  • j’ai
  • tu as
  • il/elle a
  • nous avons
  • vous avez
  • ils/elles ont
• être：是
  • je suis
  • tu es
  • il/elle est
  • nous sommes
  • vous êtes
  • ils/elles sont
• venir：来
  • je viens
  • tu viens
  • il/elle vient
  • nous venons
  • vous venez
  • ils/elles viennent
• faire：做
  • je fais
  • tu fais
  • il/elle fait
  • nous faisons
  • vous faites
  • ils/elles font
• falloir：必须，这是个绝对无人称动词
  • il faut
• devoir：必须
  • je dois
  • tu dois
  • il/elle doit
  • nous devons
  • vous devez
  • ils/elles doivent

• aimer：喜欢
  • j’aime
  • tu aimes
  • il/elle aime
  • nous aimons
  • vous aimez
  • ils/elles aiment
• parler: 说
  • je parle
  • tu parles
  • il/elle parle
  • nous parlons
  • vous parlez
  • ils/elles parlent
• prendre：take
  • je prends
  • tu prends
  • il/elle prend
  • nous prenons
  • vous prenez
  • ils/elles prennent
• sortir：出
  • je sors
  • tu sors
  • il/elle sort
  • nous sortons
  • vous sortez
  • ils/elles sortent
• rentrer：come back in
  • je rentre
  • tu rentres
  • il/elle rentre
  • nous rentrons
  • vous rentrez
  • ils/elles rentrent
• écouter：听
  • j’écoute
  • tu écoutes
  • il/elle écoute
  • nous écoutons
  • vous écoutez
  • ils/elles écoutent
• lire：读
  • je lis
  • tu lis
  • il/elle lit
  • nous lisons
  • vous lisez
  • ils/elles lisent
• ecris：写
  • j’écris
  • tu écris
  • il/elle écrit
  • nous écrivons
  • vous écrivez
  • ils/elles écrivent

• paye：付费
  • je paye
  • tu payes
  • il/elle paye
  • nous payons
  • vous payez
  • ils/elles payent
• finir:
  • je finis
  • tu finis
  • il/elle finit
  • nous finissons
  • vous finissez
  • ils/elles finissent
• courir：跑
  • je cours
  • tu cours
  • il/elle court
  • nous courons
  • vous courez
  • ils/elles courent

人称代词

重读人称代词：

• 在 C’est 后作表语
  C’est moi.
• 在介词之后
  Je suis avec toi.
• 用于表强调
• 命令式
  Regarde-toi.

• 第一人称单数
  • je
  • 所有格的阳性 mon
  • 所有格的阴性 ma
  • 所有格的复数 mes
  • 间接宾语 me
  • 重读 moi
• 第二人称单数
  • tu
  • 所有格的阳性 ton
  • 所有格的阴性 ta
  • 所有格的复数 tes
  • 间接宾语 te
  • 重读 toi
• 第三人称单数
  • il/elle
  • 所有格的阳性 son
  • 所有格的阴性 sa
  • 所有格的复数 ses
  • 间接宾语 lui
  • 重读 lui/elle
• 第一人称复数
  • nous
  • 所有格单数 notre
  • 所有格复数 nos
  • 间接宾语 nous
  • 重读 nous
• 第二人称复数
  • vous
  • 所有格单数 votre
  • 所有格复数 vos
  • 间接宾语 vous
  • 重读 vous
• 第三人称复数
  • ils/elles
  • 所有格单数 leur
  • 所有格复数 leurs
  • 间接宾语 leur
  • eux/elles
• 泛指代词
  • on
  • 重读 soi

Reference

• https://www.collinsdictionary.com/zh/conjugation/french-conjugation/aller

Filesystem In Userspace 也就是 fuse，是 linux 的一个内核模块。

Fuse 的优势在于：

• 允许非管理员权限去 mount 一个文件系统，例如 overlayfs
• 允许不通过内核实现一个文件系统

但是 Fuse 并不是在用户态访问文件系统，在调用文件系统时，依然需要陷入内核访问 VFS，并通过内核完成 IO。Fuse 在用户态做的是将内核传递的 fuse request 处理，并调用 VFS。

To FUSE or not to FUSE - Analysis and Performance Characterization of the FUSE User-Space File System Framework

2

fuse 的内核部分是 fuse.ko，会注册三个文件系统的类型：fuse、fuseblk、fusectl，它们在 /proc/filesystems 中都可见。fuse 类型的文件系统并不需要下层的块设备，而 fuseblk 类型的文件系统则需要。

fuseblk provides following features:

1. Locking the block device on mount and unlocking on release;
2. Sharing the file system for multiple mounts;
3. Allowing swap files to bypass the file system in accessing the underlying device;

fuse 和 fuseblk 都是一些不同的 FUSE 文件系统的 proxy，所以后面统称为 FUSE。

几点说明：

• FUSE 文件系统的名字一般是 [fuse|fusectl].$NAME。
• /dev/fuse 是一个块设备，被用来支持用户态的 FUSE daemon 和内核之间的通信。简单来说，用户态的 daemon 会从 /dev/fuse 中读出请求，进行处理，然后再写回到 /dev/fuse 中。

这个经典的图，是 FUSE 的链路

When a user application performs some operation on a mounted FUSE file system, the VFS routes the operation to FUSE’s kernel (file system) driver. The driver allocates a FUSE request structure and puts it in a FUSE queue. At this point, the
process that submitted the operation is usually put in a wait state.
FUSE’s user-level daemon then picks the request from the kernel queue by reading from /dev/fuse and processes the request. Processing the request might require re-entering the kernel again: for example, in case of a stackable FUSE file system, the daemon submits operations to the underlying file system (e.g., Ext4); or in case of a block-based FUSE file system, the daemon reads or writes from the block device; and in case of a network or in-memory file system, the FUSE daemon might still need to re-enter the kernel to obtain certain system services (e.g., create a socket or get the time of day).
When done with processing the request, the FUSE daemon writes the response back to /dev/fuse; FUSE’s kernel driver then marks the request as completed, and wakes up the original user process which submitted the request.

一些文件系统的操作并不需要和用户态的 FUSE daemon 交流，就可以完成。例如，读一个之前读过的文件，因为它的 page 已经被存在 page cache 里面了，所以就不需要再把请求 forward 给 FUSE driver 了。这里可能被 cache 的不仅包括 data，还包括一些 meta data。例如 stat 查询 inode 和 dentry 的信息，它们被存在 Linux 的 dcache 中，可以直接在内核态处理，而不需要调用 FUSE daemon 了。

2.2 User-Kernel Protocol

2.3 Library and API Levels

High-level 的 API 允许开发者跳过 path-to-inode 映射。或者说 inode 在 high level API 中根本不存在了，high level API 只操作路径。FORGET inode method 根本就不需要了。

无论是 high 还是 low level，反正大概都是要实现 42 个方法。

2.4 Queues

一个请求在同一时间只能属于下面五个队列的其中一个。

FORGET requests are sent when the inode is evicted, and these requests are would queue up together with regular file system requests, if a separate forgets queue did not exist. 如果有大量的 FORGET 请求，就无法处理其他的文件系统请求了。这个行为是在一个有 3200 万的 inode 节点上看到的，当所有的 inode 被从 icache evict 的时候，系统可能会 hang 大概 30min。

pending queue 中是同步请求。

当 daemon 从 /dev/fuse 中读取时，会以下面的顺序：

• 最高优先级会处理 Interrupts 队列中的请求
• FORGET 和非 FORGET 请求会被公平地选择，处理完 8 个非 FORGET 请求，会再处理 16 个 FORGET 请求。这也保障了 FORGET 请求不会堆积起来。

请求处理的流程是：

• pending queue 中最老的请求会被传送到 user space，然后被 processing queue 立即处理。
  INTERRUPT 和 FORGET 队列并不会从 user daemon 获得回复，所以当 daemon 读取这些请求的时候，它们就终止了。
• 如果 pending queue 上没有请求，那么 FUSE daemon 就会阻塞在一个 read 调用上。
• 如果 daemon 回复了，对应的请求就会被从 processing queue 中被移除，这个请求就完成了。同时，blocked user processes (e.g., the ones waiting for READ to complete) are notified that they can proceed.

background queue 是对异步请求的。默认情况下，只有读是异步的，因为可以 read ahead。如果开启 writeback cache，则 write 也会走到 background queue 中。开启 writeback cache 后，从 user process 来的 write 会先聚集在 page cache 中，然后 bdflush 线程会醒来，去刷脏页。

background queue 中的请求会一点点汇到 pending queue 中，在 pending queue 中的异步请求的数量是根据 max_background 参数（默认 12）来调整的。目的是：

• 避免异步请求影响同步请求
• 开启 multi-threaded 选项后，限制 user daemon 线程的数量

2.5 Splicing and FUSE Buffers

在初始设置中，FUSE daemon 需要从 /dev/fuse 中读取请求，并且把回复也写到这个设备中。这样在内核和用户态之间复制内存，对 read 和 write 请求是有害的，因为通常它们会包含很多数据。因此，FUSE 会使用 Linux kernel 提供的 splice 技术。

splice() 系列的系统调用可以在两个 in-kernel memory buffer 之间传递数据，这样就不需要到用户态拷贝一次了。

例如 sendfile、mmap、splice 都是 Linux 中的零拷贝技术，主要是消除一些不需要的拷贝

FUSE 将它的 buffer 表示为下面两种形式之一：

• The regular memory region identified by a pointer in the user daemon’s address space, or
• The kernel-space memory pointed by a file descriptor of a pipe where the data resides.

If a user-space file system implements the write_buf() method (in the low-level API), then FUSE first splices the data from /dev/fuse to a Linux pipe and then passes the data directly to this method as a buffer containing a file descriptor of the pipe. FUSE splices only WRITE requests and only the ones that contain more than a single page of data.

Similar logic applies to the replies to READ requests if the read_buf() method is implemented. However, the read_buf() method is only present in the high-level API; for the low-level API, the file-system developer has to differentiate between splice and non-splice flows inside the read method itself.

下面这段话讲解了为什么 header 肯定得 copy

If the library is compiled with splice support, the kernel supports it, and appropriate commandline parameters are set, then splice() is always called for every request (including the request’s header). However, the header of every single request needs to be examined, for example to identify the request’s type and size. This examination is not possible if the FUSE buffer has only the file descriptor of a pipe where the data resides. So, for every request the header is then read from the pipe using regular read() calls (i.e., small, at most 80 bytes, memory copying is always perfomed). FUSE then splices the requested data if its size is larger than a single page (excluding the header): therefore only big writes are spliced. For reads, replies larger than two pages are spliced.

扩展

注意，上文中得到的那个 pipe，实际上是可以方便地把数据通过 pipe 的形式往下游传递的。应该是对应了第二种 buffer 的形式。

vmsplice 并不能把管道里面的数据移动到用户态内存中，所以如果需要在用户态对数据进行处理，例如需要加解密或者加解压，则得 Copy。

1
2
3
4
5
6
7
8
9
10
11

/** Write contents of buffer to an open file
 *
 * Similar to the write() method, but data is supplied in a
 * generic buffer.  Use fuse_buf_copy() to transfer data to
 * the destination.
 *
 * Unless FUSE_CAP_HANDLE_KILLPRIV is disabled, this method is
 * expected to reset the setuid and setgid bits.
 */
int (*write_buf) (const char *, struct fuse_bufvec *buf, off_t off,
          struct fuse_file_info *);

2.6 Notifications

FUSE 可以通过回复内核的 request 向内核传递消息。但有时候，它需要主动向内核传递消息，比如 poll 调用时，如果事件发生了，FUSE 需要主动通知内核。

2.7 Multithreading

如果 pending queue 里面有多个请求，FUSE 会启动新的线程。每个线程处理一个请求，我理解这里是内核线程。处理完后，会检查是否有超过 10 个线程，如果是，则线程退出。

There is no explicit upper limit on the number of threads created by the FUSE library.
The implicit limit arises due to two factors.

• First, by default, only 12 asynchronous requests (max background parameter) can be in the pending queue at one time.
• Second, the number of synchronous requests in the pending queue is constrained by the number of user processes that submit requests.
• In addition, for every INTERRUPT and FORGET requests, a new thread is invoked.

Therefore, the total number of FUSE daemon threads is at most (12 + number of processes with outstanding I/O + number of interrupts + no of forgets).

2.8 Linux Write-back Cache and FUSE

2.8.1 Linux Page Cache

Page cache 的作用是减少 disk IO，行为是将数据存在 RAM 里面。

对于读，就是很简单的 cache。对于写，是三个策略：

• no-write 直接写 disk，invalidate cache
• write-through 写 disk 也写 cache
• write-back 只写 cache，后续异步写 disk。这些中间状态的 page 也被称为 dirty page

刷 diety page 发生在三个情况：

• free memory 低于阈值
• dirty data 比某个阈值老了
• 用户调用了 sync 或者 fsync

All of the above three tasks are performed by the group of flusher threads. First, flusher threads flush dirty data to disk when the amount of free memory in the system drops below a threshold value.
This is done by a flusher thread calling a function bdi_writeback_all, which continues to write data to disk until following two conditions are true:

1. The specified number of pages has been written out; and
2. The amount of free memory is above the threshold.

在 2.6 内核前，内核中有 bdflush 和 kupdated 两个线程，它们的作用和现在的 flusher 一样：

• bdflush 负责后台 writeback dirty page，当 free memory 变少的时候
• kupdated 负责周期性地 writeback dirty page

The major disadvantage in bdflush was that it consisted of one thread. This led to congestion during heavy page writeback where the single bdflush thread blocked on a single slow device.

在 2.6 内核中，引入了 pdflush 这种线程，它们会根据 io load 调整为 2 到 8 中间的数量。The pdflush threads were not associated with any specific disk, but instead they were global to all disks. The downside of pdflush was that it can easily bottleneck on congested disks, starving other devices from getting service.

Therefore, a per-spindle flushing method was introduced to improve performace. The flusher threads replaced the pdflush threads in the 2.6.32 kernel.

The 2.6.32 kernel solved this problem by enabling multiple flusher threads to exists where each thread individually flushes dirty pages to a disk, allowing different threads to flush data at different rates to different disks. This also introduced the concept of per-backing device info (BDI) structure which maintains the per-device (disk) information like dirty list, read ahead size, flags, and B.D.Mn.R and B.D.Mx.R which are discussed in the next section.

2.8.2 Page Cache Parameters

Global Background Ratio (G.B.R): The percentage of Total Available Memory filled with dirty pages at which the background kernel flusher threads wake up and start writing the dirty pages out. The processes that generate dirty pages are not throttled at this point. G.B.R can be changed by the user at /proc/sys/vm/dirty_background_ratio. By default this value is set to 10%.

Global Dirty Ratio (G.D.R): The percentage of Total Available Memory that can be filled with dirty pages before the system starts to throttle incoming writes. When the system gets to this point, all new I/O’s get blocked and the dirty data is written to disk until the amount of dirty pages in the system falls below this G.D.R. This value can be changed by the user at /proc/sys/vm/dirty ratio. By default this value is set to 20%.

Global Background Threshold (G.B.T): The absolute number of pages in the system that, when crossed, the background kernel flusher thread will start writing out the dirty data. This is obtained from the following formula:
G.B.T = T otalAvailableMemory × G.B.R

Global Dirty Threshold (G.D.T): The absolute number of pages that can be filled with dirty pages before the system starts to throttle incoming writes. This is obtained from the following formula:
G.D.T = T otalAvailableMemory × G.D.R

下面两个参数主要是限制不同设备能够使用的 page cache 的比例

BDI Min Ratio (B.Mn.R): Generally, each device is given a part of the page cache that relates to its current average write-out speed in relation to the other devices. This parameter gives the minimum percentage of the G.D.T (page cache) that is available to the file system. This value can be changed by the user at /sys/class/bdi/<bdi>/min ratio after the mount, where <bdi> is either a device number for block devices, or the value of st_dev on non-block-based file systems which set their own BDI information (e.g., a fuse file system). By default this value is set to 0%.

BDI Max Ratio (B.Mx.R): The maximum percentage of the G.D.T that can be given to the file system (100% by default). This limits the particular file system to use no more than the given percentage of the G.D.T. It is useful in situations where we want to prevent one file system from consuming all or most of the page cache.

BDI Dirty Threshold (B.D.T): The absolute number of pages that belong to write-back cache that can be allotted to a particular device. This is similar to the G.D.T but for a particular BDI device. As a system runs, B.D.T fluctuates between the lower limit (G.D.T × B.Mn.R) and the upper limit (G.D.T × B.Mx.R).

BDI Background Threshold (B.B.T): When the absolute number of pages which are a percentage of G.D.T is crossed, then the background kernel flusher thread starts writing out the data. This is similar to the G.B.T but for a particular file system using BDI. B.B.T = B.D.T × G.B.T / G.D.T

NR FILE DIRTY: The total number of pages in the system that are dirty. This parameter is incremented/decremented by the VFS (page cache).

NR WRITEBACK: The total number of pages in the system that are currently under write-back. This parameter is incremented/decremented by the VFS (page cache).

BDI RECLAIMABLE: The total number of pages belonging to all the BDI devices that are dirty. A file system that supports BDI is responsible for incrementing/decrementing the values of this parameter.

BDI WRITEBACK: The total number of pages belonging to all the BDI devices that are currently under write-back. A file system that supports BDI is responsible for incrementing/decrementing the values for this parameter.

Implementations

主要是做了一个 stackfs。

主要介绍了下面几个方面：

• inode
• lookup
• session information
  主要是是每个 FUSE session/connection 的数据管理。
• directories
• file create and open

Stackfs assigns its inode the number equal to the address of the inode structure in memory (by type-casting)

也就是说，Stackfs 的 inode number 数值上是等于 inode struct 的地址的。而 FUSE 的 high level API 中，需要维护 FUSE inode number 到 inode struct 所在位置的映射关系。

Methodology

FUSE has evolved significantly over the years and added several useful optimizations: a writeback cache, zero-copy via splicing, and multi-threading. In our experience, some in the storage community tend to pre-judge FUSE’s performance—assuming it is poor—mainly due to not having enough information about the improvements FUSE has made over the years.

为了比较近年来 FUSE的优化：

• StackfsBase
• StackfsOpt -> 包含了所有的 FUSE 优化项目
  • writeback cache
  • 单个 FUSE 请求的最大尺寸 4KiB -> 128KiB
  • user daemon 跑在 muitl-thread，也就是 fuse_session_loop_mt
  • splicing is activated for all operations，应该指的是 splice 这个零拷贝技术

一些补充

FUSE 和 zero copy

如之前的图所示，FUSE 的通信模型如下。FUSE 中的一些过程是可以被 Zero-Copy 的，具体如 Splicing and FUSE Buffers 这一章节所讲的：

• WRITE 部分有限制地给超过一个 page 的数据开启 splice 功能
• READ 部分也无法避免直接读取 header

FUSE 并不能完全实现零拷贝，原因主要在需要访问 /dev/fuse。

/dev/fuse 这个设备很像是一个 rpc 调用，kernel 向它写入一些命令，例如 READ、OPEN 等，而 daemon 会从这个设备读出这些命令。daemon 会往 /dev/fuse 中写 response。

命令大概如下

1

[ header | payload ]

不能使用 mmap 实现 zero copy 的原因：FUSE daemon 是普通用户进程，所以在设计上就允许它 crash、被攻击、卡死等情况。而如果使用 mmap，则内核很难控制生命周期。例如当 FUSE daemon 挂掉之后，需要考虑谁来清理掉这些 mmap 的文件。

一些知识

零拷贝

见 Zero-Copy 技术

Reference

• https://www.fsl.cs.sunysb.edu/docs/fuse/bharath-msthesis.pdf
  完整版论文
• https://github.com/0voice/kernel_awsome_feature/blob/main/Fuse/FUSE.pdf
• https://github.com/libfuse/libfuse/blob/master/example/passthrough.c
  一个最简单的 demo
• https://github.com/0voice/kernel_awsome_feature/blob/main/%E8%87%AA%E5%88%B6%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%20%E2%80%94%2003%20Go%E5%AE%9E%E6%88%98%EF%BC%9Ahello%20world%20%E7%9A%84%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F.md

Editor’s Note

Years of political training and experience had taught Hacker to use twenty words where one would do, to dictate millions of words where mere thousands would suffice, and to use language to blur and fudge issues and events so that they became incomprehensible to others. Incomprehensibility can be a haven for some politicians, for therein lies temporary safety.

But his natural gift for the misuse of language, though invaluable to an active politician, was not an asset to a would-be author.

OPEN GOVERMENT

电视剧中增加了一段误接 BBC 采访电话的剧情，我觉得挺棒的。

‘Then why don’t you marry him?’ she asked. ‘I now pronounce you man and political adviser. Whom politics has joined let no wife put asunder.’

THE OFFICIAL VISIT

‘Shall we scramble?’ he said.
‘Where to?’ I said, then felt rather foolosh as I realised what he was talking about. Then I relised it was another of Bernards’s draft suggestions: what’s the point of scrambling a phonw conversation about something that’s just been on the television news?

scramble 既有匍匐前进、攀登的意思，也有干扰无线电，使得只有特殊的人才能够听到通话的意思。

And if the new president is Marxist-backed, who better to win him over to our side than Her Majesty?

如果新总统背后有马克思主义支持，还有谁比陛下更能说服他站到我们这边呢？

there was one 747 that belonged to nine different African airlines in one month. They called it the mumbo-jumbo.

THE ECONOMY DRIVE

I was forced to move on to the next two white elephants.

我被迫继续处理接下来的那两个烫手山芋。

‘Government buildings do not need fire fafety clearance’
‘Why?’
‘Perhaps,’ Humphrey offered, ‘because Her Majesty’s Civil Servants are not easily inflamed.’

Frank chimed in eagerly, ‘Yes, that would get rid of ninety civil servants at a stroke.’
‘Or indeed,’ said Sir Humphrey, ‘at a strike.’

后面还有经典的 smile at 和 smile on。

BIG BROTHER

The local party, the constituency, my family, all of them are proud of me for getting into the Cabinet – yet they are all resentful that I have less time to spend on them and are keen to remind me that I’m nothing special, just their local MP, and that I mustn’t get ‘too big for my boots’. They manage both to grovel and patronise me simultaneously. It’s hard to know how to handle it.

And he assumes, rightly, that the Minister has too much else to do. [The whole process is called Creative Inertia – Ed.]

He also warned me of the ‘Three Varieties of Civil Service Silence’, which would be Humphrey’s last resort if completely cornered:
The silence when they do not want to tell you the facts: Discreet Silence.
The silence when they do not intend to take any action: Stubborn Silence.
The silence when you catch them out and they haven’t a leg to stand on. They imply that they could vindicate themselves completely if only they were free to tell all, but they are too honourable to do so: Courageous Silence.

I explained to her that the Opposition aren’t really the opposition. They’re just called the Opposition. But, in fact, they are the opposition in exile. The Civil Service are the opposition in residence.

In the second place, if there had been investigations, which there haven’t or not necessarily, or I am not at liberty to say if there have, there would have been a project team which, had it existed, on which I cannot comment, would now be disbanded if it had existed and the members returned to their original departments, had there indeed been any such members.

经典虚拟语气。

But they’ve convinced me that they can. Indeed my Permanant Secretary is staking his reputation on it. And, if not, heads will roll.

Hacker 对媒体的了解，经典的媒体逼宫战术。在后面的交通总管一事中，也被 PM 用来赶鸭子上架。

THE WRITING ON THE WALL

Woe betide any Minister who lifts the phone to try to sort out a foreign trade deal, for instance.

Woe betide 在一起表示 XXX 样就会倒霉。Betide 的意思是降临。

‘With respect, Minister,’ countered Sir Humphrey (untruthfully), ‘how do you know it says the opposite if it is totally unintelligible?’

这次是 Humphrey 而不是 Bernard 来挑逻辑问题。

Hacker was beginning to understand Civil Service code language. Other examples are:
‘I think we have to be very careful.’ Translation: We are not going to do this.
‘Have you thought through all the implications?’ Translation: You are not going to do this.
‘It is a slightly puzzling decision.’ Translation: Idiotic!
‘Not entirely straightforward.’ Translation: Criminal.
‘With the greatest possible respect, Minister . . .’ Translation: Minister, that is the silliest idea I’ve ever heard

这是 Editor 的总结，我觉得很有趣。

If a purely hypothetical Minister were to be unhappy with a departmental draft of evidence to a committee, and if the hypothetical Minister were to be planning to replace it with his own hypothetical draft worked out with his own political advisers at his party HQ, and if this Minister was planning to bring in his own draft so close to the final date for evidence that there would be no time to redraft it, and if the hypothetical Private Secretary were to be aware of this hypothetical draft – in confidence – should the hypothetical Private Secretary pass on the information to the Perm. Sec. of the hypothetical Department?

经典虚拟语气片段。

‘We shall always support you as your standard-bearer, Minister but not as your pall-bearer.’

‘If you must do this damn silly thing,’ he said, ‘don’t do it in this damn silly way.’

Humphrey 难得的两次很直的话。

Bernard assured me that I didn’t really need to know much about the proposal because his information on the grapevine, through the Private Office network, was that the proposal would go through on the nod.

为啥 grapevine 还有小道消息的意思？

Donald Hughes, rubbing salt in the wound, apparently described it as ‘approbation, elevation and castration, all in one stroke’. It seems he suggested that I should take the title Lord Hacker of Kamikaze.

I told Humphrey I was appalled.
‘You’re appalled?’ he said. ‘I’m appalled.’
Bernard said he was appalled, too. And, there’s no doubt about it, the situation is appalling.

Industrial Harmony. That means strikes.

这里 Editor 有个注解，挺有趣的。

You’ll probably spend the rest of your career in the Vehicle Licensing Centre in Swansea.

对 Swansea 很有敌意啊。

Then Humphrey proposed that we work together on this. This was a novel suggestion, to say the least.

‘I’m awfully sorry to quibble again, Minister, but you can’t actually stop things before they start,’ intervened Bernard, the wet-hen-in-chief. He’s really useless in a crisis.

‘Same reason,’ came the reply. ‘It’s just like the United Nations. The more members it has, the more arguments you can stir up, and the more futile and impotent it becomes.’

感觉很有洞见。

Then I had an idea. I suddenly realised that Martin will be on my side. I can’t imagine why I didn’t think of it before. He’s Foreign Secretary – and, to my certain knowledge, Martin is genuinely pro Europe. (Humphrey calls him ‘naïf’). Also I ran his campaign against the PM, and he only stands to lose if I’m squeezed out.

I agreed, and remarked that this Europass thing is the worst disaster to befall the government since I was made a member of the Cabinet. [We don’t think that Hacker actually meant what he seems to be saying here Ed.]

It’s awarded to the statesman who has made the biggest contribution to European unity since Napoleon. [That’s if you don’t count Hitler – Ed.]

这几段 Editor 的注解都很有趣。

when you’ve got them by the balls, their hearts and minds will follow.

THE RIGHT TO KNOW

Sir Humphrey replied that I need not look far – Private Secretaries who could not occupy their Ministers were a threatened species.

‘Almost anything can be attacked as a loss of amenity and almost anything can be defended as not a significant loss of amenity. One must appreciate the significance of significant.’

Humphrey suggested I look inside them. I did, and to my utter astonishment I saw that there were a handful of signatures in each book, about a hundred altogether at the most. A very cunning ploy – a press photo of a petition of six fat books is so much more impressive than a list of names on a sheet of Basildon Bond.

Those civil servants are always kowtowing to Daddy, but they never take any real notice of him.

Kowtow 就是中文的磕头。

She told me she’d been out with the trots. I was momentarily sympathetic and suggested she saw the doctor. Then I realised she meant the Trotskyites. I’d been slow on the uptake because I didn’t know she was a Trotskyite. Last time we talked she’d been a Maoist.

I noted that Lucy was giving out the press release at five p.m. Very professional. Misses the evening papers, which not too many people read, and therefore makes all the dailies. She’s learned something from being a politician’s daughter.

JOBS FOR THE BOYS

you scratch my back, I’ll scratch yours.

THE COMPASSIONATE SOCIETY

比较好奇为什么 DAA 会为医院的铺张浪费负责？

I informed Bernard that most of our journalists are so amateur that they would have grave difficulty in finding out that today is Thursday.
‘It’s actually Wednesday, Minister,’ he said.

Sir Humphrey preferred to write in margins where possible, but, if not possible, simulated margins made him feel perfectly comfortable.

We can infer from this note that Mr Bernard Woolley – as he then was – mentioned the matter of St Edward’s Hospital to Sir Humphrey, although when we challenged Sir Bernard – as he now is – on this point he had no recollection of doing so – Ed.

THE DEATH LIST

DOING THE HONOURS

比较好奇为什么 DAA 会管到教育的事情？

Chat over the port and walnuts

通常用来描述一种轻松的社交场合，人们在享用波特酒（port）和核桃（walnuts）时进行闲聊。

He explained that home students were to be avoided at all costs! Anything but home students.

Sir William Guthrie, OM, FRS, FBA, Ph.D, MC, MA (Oxon)
Group Captain Christopher Venables, DSC, MA
Sir Humphrey Appleby, KCB, MVO, MA (Oxon)
Bernard Woolley, MA (Cantab)
The Rt Hon. James Hacker, PC, MP, BSc. (Econ)
Sir Arnold Robinson, GCMG, CVO, MA (Oxon)

Cantab 指的是剑桥。

In fact, the only time a civil servant is known to have refused a knighthood was in 1496. This was because he already had one.

Just as incomes policies have always been manipulated by those that control them: for instance, the 1975 Pay Policy provided exemptions for Civil Service increments and lawyers’ fees. Needless to say, the policy was drafted by civil servants and parliamentary draftsmen, i.e. lawyers.

Quis custodiet ipsos custodes?

And how did the civil servants get away with creating these remarkably favourable terms of service for themselves? Simply by keeping a low profile. They have somehow managed to make people feel that discussing the matter at all is in rather poor taste.

很有趣的观察，“保持低调”，“讨论这些并不得体”。

Cut no ice with me
俗语，表示 XX 对我没用。

The penny dropped
俗语，表示某人终于明白了某件事情或某人突然明白了之前不明白的事情。

‘There is no reason,’ he said, stabbing the air with his finger, ‘to change a system which has worked well in the past.’
‘But it hasn’t,’ I said.
‘We have to give the present system a fair trial,’ he stated. This seemed quite reasonable on the face of it. But I reminded him that the Most Noble Order of the Garter was founded in 1348 by King Edward III. ‘Surely it must be getting towards the end of its trial period?’ I said.
So Humphrey tried a new tack. He said that to block honours pending economies might create a dangerous precedent. What he means by ‘dangerous precedent’ is that if we do the right thing now, then we might be forced to do the right thing again next time. And on that reasoning nothing should ever be done at all.

‘How do they award the Thistle?’ I asked.
‘A committee sits on it,’ said Bernard

双关。

‘As you know,’ he said, ‘the letters JB are the highest honour in the Commonwealth.’
I didn’t know.
Humphrey eagerly explained. ‘Jailed by the British. Gandhi, Nkrumah, Makarios, Ben-Gurion, Kenyatta, Nehru, Mugabe – the list of world leaders is endless and contains several of our students.’

although the Cabinet Secretary is theoretically primus inter pares he is in reality very much primus. It seems that all Permanent Secretaries are equal but some are more equal than others.

thin end of the wedge

Perhaps Appleby is not an absolutely first-rank candidate to succeed one as Cabinet Secretary. Not really able in every department. Might do better in a less arduous job, such as chairman of a clearing bank or as an EEC official.

‘Of course,’ said Bernard, ‘but it’s years and years since the Department of Transport had a Permanent Secretary from Cambridge.’
好像只有 Bernard 是剑桥的。

THE GREASY POLE

“The Greasy Pole” is an idiomatic expression used to describe the difficult and often slippery route to advancement in one’s career or profession. It is particularly used in contexts where success is hard to achieve and the path to the top is fraught with challenges and obstacles

‘Simple, Minister,’ he explained. ‘It means “with” or “after”, or sometimes “beyond” – it’s from the Greek, you know.’
[Like all Permanent Secretaries, Sir Humphrey Appleby was a generalist. Most of them studied classics, history, PPE or modern languages. Of course you might expect the Permanent Secretary at the Department of Administrative Affairs to have a degree in business administration, but of course you would be wrong – Ed.]
Then he went on to explain that metadioxin means ‘with’ or ‘after’ dioxin, depending on whether it’s with the accusative or the genitive: with the accusative it’s ‘beyond’ or ‘after’, with the genitive it’s ‘with’ as in Latin, where the ablative is used for words needing a sense of with to precede them.
Bernard added – speaking for the first time in the whole meeting – that of course there is no ablative in Greek, as I would doubtless recall.
I told him I recalled no such thing, and later today he wrote me a little memo, explaining all the above Greek and Latin grammar.

‘Well,’ he said eventually, ‘inert means that . . . it’s not . . . ert.’

I searched desperately for an analogy, ‘It’s like Littler and Hitler,’ I explained. ‘We’re not saying that you’re like Hitler because your name sounds similar.’

Stage two: Discredit the evidence that you are not publishing
This is, of course, much easier than discrediting evidence that you do publish. You do it indirectly, by press leaks. You say:
(a) that it leaves important questions unanswered
(b) that much of the evidence is inconclusive
(c) that the figures are open to other interpretations
(d) that certain findings are contradictory
(e) that some of the main conclusions have been questioned
Points (a) to (d) are bound to be true. In fact, all of these criticisms can be made of a report without even reading it. There are, for instance, always some questions unanswered – such as the ones they haven’t asked. As regards (e), if some of the main conclusions have not been questioned, question them! Then they have.

这里，有两幅 BBC 的报道，分别是支持和反对某个事情的版本，不过太模糊看不清楚。

‘The public,’ said Sir Humphrey, ‘are ignorant and misguided.’
‘What do you mean?’ I demanded. ‘It was the public who elected me.’

He was very bitter. And very insulting. ‘Must you always be so concerned with climbing the greasy pole?’
I faced the question head on. ‘Humphrey,’ I explained, ‘the greasy pole is important. I have to climb it.’
‘Why?’
‘Because,’ I said, ‘it’s there.’

I asked him how it felt, going from the Commons to the Lords.
‘It’s like being moved from the animals to the vegetables,’ he replied.

THE DEVIL YOU KNOW

He sighed. ‘Well, Minister, I’m afraid that this is the penalty we have to pay for trying to pretend that we are Europeans. Believe me, I fully understand your hostility to Europe.’

I reminded Humphrey that the typical Common Market official is said to have the organising capacity of the Italians, the flexibility of the Germans and the modesty of the French. He tops all that up with the imagination of the Belgians, the generosity of the Dutch, and the intelligence of the Irish. Finally, for good measure, he has the European spirit of Mr Anthony Wedgwood Benn.

THE BED OF NAILS

如坐针毡还有的表述是：On Tenterhooks

常见单词