本文的内容主要参考了filebench在USENIX ;login:'16上的文章（正值filebench 1.5发布）和官方仓库的wiki，filebench从2005年开源到今天已经过去了18年了，github最后一次commit截止在了3年前，之后也没有维护过了，不过filebench目前已经比较完善了，也得到了学术界比较广泛的认可，到今天依然还能拿来跑一些benchmark。本篇文章主要目的是解释一些filebench中的参数，几个预定义工作负载，最后来介绍如何使用filebench来测试ZNS的性能。
本文首次将学习索引应用到了LSM-tree之中，基于Whiskey Key-Value分离存储的开创性工作，使得对LSM-tree建立学习索引成为可能（定长SSTable entry）。文章通过详细的实验分析说明了学习索引加速LSM-tree Lookup的性能提升，并指出在未来高性能SSD/存储设备上学习索引能带来更大的收益。
这篇文章写作很多地方没有说清楚，motivation部分描述实验负载时不够清楚，第三个实验/observation看了很久才看出来是想表达什么问题。文章的三个主要设计都围绕motivation中的三个问题，整体的设计思想有点类似于将应用和固态盘namespace绑定，按照调度应用I/O的思想来管理ZNS中Zone的资源。
Introduction to Cgroups Cgroups, which called control group in Linux to limit system resources for specify process group, is comonly used in many container tech, such as Docker, Kubernetes, iSulad etc.
The cgroup architecture is comprised of two main components:
the cgroup core: which contains a pseudo-filesystem cgroupfs, the subsystem controllers: thresholds for system resources, such as memory, CPU, I/O, PIDS, RDMA, etc. The hierarchy of Cgroups In Cgroups v1, per-resource (memory, cpu, blkio) have it’s own hierarchy, where each resource hierarchy contains cgroups for that resource.
HadaFS，一个为超算提供本地和共享Burst Buffer的文件系统
0x00 Intro 现代的超算通过SSD来实现Burst Buffer（BB）layer。
根据部署位置，BB可以分为两种：
Local BB，作为本地硬盘部署在每个计算节点上，有高伸缩性和性能 Shared BB，部署在专用节点上，可以被多个计算节点访问，可以共享数据，部署成本低 HadaFS已经部署在了神威新一代超算（Sunway New- generation Supercomputer，SNS）中。支持最大600000用户，最大I/O带宽3.1TB/s。
Burst Buffer作为数据加速层，一般使用SSD。自2016年起，越来越多的超算开始使用Burst Buffer。
对于local BB，有一些局限性：
由于难以进行数据共享，Local BB不适用于所有场景，例如N-1 I/O mode，所有进程共享一个文件、workflow 由于超算程序之间的I/O负载差异较大，而数据密集型应用的比例较低，造成了大量的资源浪费 随着超算规模的扩大，local BB的部署成本未来会急剧升高 相比于Local BB，Share BB便于数据共享，部署成本低，但是在超算上部署也面临许多问题。LPCC将SSD集成到Lustre FS Client，提高read/write性能的一种缓存技术，LPCC存储在Lustre client SSD中的数据必须先刷新到Lustre server才能进行共享。BeeOND类似于LPCC，继承了BeeGFS的可伸缩性和缓存共享限制。
超算的发展使得并行I/O需求增加，BB架构相较于传统GFS有着同样的高性能，但是容量较小，因此BB要与GFS进行整合。目前的BB架构数据迁移的效率很低，浪费了很多计算资源，因此高伸缩性的BB数据管理和迁移也是目前要解决的问题。
为了解决这个问题，作者提出了BB File System–HadaFS。
基于share BB，结合了local BB的伸缩性、性能优势和share BB的数据共享、部署成本低的优点。
HadaFS提供Localized Triage Architecture（LTA）局部分类架构，解决了shared BB伸缩性不足的问题，实现了超大规模的扩展和数据共享，LTA将所有HadaFS server构建为一个共享存储池，可以在client和server之间灵活的控制并发问题，来保证数据共享。 HadaFS提出了一个运行时的user-level接口，来保证来自client的I/O请求可以被最近的server处理，类似local BB。 为了解决由POSIX接口强一致性导致的性能问题，HadaFS提出了一种包含三种元数据同步机制的全路径索引方法，来解决传统文件系统在复杂元数据的管理上的问题，以及文件系统和应用I/O行为不匹配的问题。使用KV的方法来代替传统的目录树结构。 HadaFS集成了数据管理工具，帮助用户管理BB中的数据，完成BB和GFS之间的高效数据迁移。 提出Hadash，在BB中提供高效的数据查询，加速BB和传统超算存储的数据迁移。 0x01 Motivation && Bg Motivation BB可伸缩性和应用行为的矛盾 随着超算百亿亿次计算记录的打破，尖端超算中的I/O并行可以达到数十万，加大了BB在伸缩性上的压力。
目前的一些顶尖超算：
Frontier使用独立的硬件来分别构造local BB和shared BB，需要使用大量的SSD和高昂的建设维护成本。 Fugaku使用shared BB，使用软件来提供存储服务，local BB和shared BB使用不同的name space。这种方式是静态的，很难控制在高并发情况下的I/O竞态问题。 Summit部署local BB，支持数据在应用之间的共享，基于GFS，效率较低。 由于shared BB既可以用于计算节点，也可以用于数据转发节点，作者相信shared BB更适合超级计算机。
本文记录FEMU blackbox ssd（ssd对主机透明）的源码阅读。
bb.c 用于注册bbssd，在hw/femu/femu.c>nvme_register_extesions()中执行
1 2 3 4 5 6 7 8 9 10 11 12 static int nvme_register_extensions(FemuCtrl *n) { if (OCSSD(n)) { ... } ... } else if (BBSSD(n)) { nvme_register_bbssd(n); } ... return 0; } 这个FemuCtrl *n结构包含了很多内容，本质上是一个用于线程之间同步/传值的结构
1 2 3 4 5 6 7 8 9 10 11 12 13 14 int nvme_register_bbssd(FemuCtrl *n) { n->ext_ops = (FemuExtCtrlOps) { .state = NULL, .init = bb_init, .exit = NULL, .
