Words

mediate v. 调节，斡旋

negligible adj. 微不足道的

Insight

传统服务器通过内核协调进程隔离和网络、磁盘等IO设备的安全性，本文实现了一个操作系统，允许应用程序IO跳过内核。也就是所谓的控制平面和数据平面分离。

Achievement

一个典型NoSQL场景下的存储延迟优化了2-5倍，吞吐量提高了9倍

提出了一种分工架构，并实现了一个原型操作系统，在此基础上测量了一部分现实服务的性能

Breakdown Analysis

从网络开始，传统Linux接受一个网络包的时间在微秒级别，通常是3us、6us两个时间级别，差别在于收包进程是否在idle，并且相差的开销以schedule带来的开销为主。而在3us中，主要的时间都浪费在了网络栈上。主要的开销集中于以下四点

• 网络栈开销
• 调度器开销
• 内核切换开销
• 数据包复制开销
• 除此之外，多核导致的缓存和锁也会增加开销

Arrakis可以完全消除调度器和内核切换的开销，并且极大的消除了网络栈和数据包复制的影响。

同时文章分析了在存储侧系统调用带来的影响，以1KB为例，ext4的CPU开销大概要在30us级别，btrfs在70us级别，而RAID缓存的写延迟大概25us，闪存低至15us，这意味着文件系统带来的开销甚至要比硬件写入的开销更大。

后续的阅读中我可能没再关注网络侧的内容，主要关注Storage，以及他们提出的这种硬件模型所提供的能力及用途。

Design&Imp

文章描述了一个基于一类特定的（主要是硬件级别支持虚拟化的）IO设备的架构。现有设备和控制器只能在某些方面实现他们提出的这种硬件模型。

访问层级主要分为App、LibOS、VSIC、VSA和Device。

App通过定制的UserSpace Lib来访问VSIC，即虚拟存储界面控制器，同时，硬件设备需要将物理段映射为多个虚拟存储区域VSA，VSA和VSIC是一个多对多的映射关系，VSIC由App创建。App通过API可以通过VSIC中的命令队列读取、写入VSA中任意偏移和大小的磁盘，完成使用doorbell通知。

整个用户访问文件的流程不需要操作系统介入。那么问题就到了文件是如何共享和访问控制的。

Arrakis分离了文件的命名和实现。App可以任意的通过VSA存储metadata和文件等内容。并可以将文件、目录名导出到vfs中，仍由原App管理，外部的访问不会被内核干预。外部访问可以通过RPC把原APP当做一个Server访问，或者源程序提供一个可以独立运行的进程。

VSA也可以映射到多个进程中，此时访问APP需要能读到原APP的metadata，并能有适当的库解析文件内容。访问控制控制整个VSA是否可见。

用户可以直接导出文件为标准格式。

我感觉这三个方案都有点过于牵强了。