by ·0 Comments

本文概述 HotCloud ’18 中的一篇讲云原生文件系统的论文，来回顾下存储领域大佬 Arpaci-Dusseau 在 6 年前对云原生文件系统的想法。论文链接 hotcloud18-paper-arpaci-dusseau.pdf (usenix.org) 文章的贡献主要有两点： 提出一些云原生文件系统所应该遵循的设计原则； 提出一种云原生文件系统 CNFS 的大概设计。 云原生文件系统的设计原则 作者把设计的原则分为存储和计算两个层次，但总体来讲都聚焦于成本和性能的权衡。这种权衡是云环境相对传统环境更容易做到的，也是云原生文件系统设计的核心。 存储原则 可靠性已经通过更底层的云存储服务得到保障。云存储比如对象存储 S3 或者块存储 EBS，已经提供了多副本等可靠性功能，因此云原生文件系统可以把这部分功能卸载到更底层的云存储。 云存储空间便宜且可以无限扩展。云原生文件系统的设计应该尽量利用这些便宜的存储空间对数据建立索引，用空间换时间。 云存储与本地存储有很大差异：带宽通常较高；延迟根据服务分级不同差异明显；更快分级的云存储访问成本反而更低。因此云原生文件系统应该按冷热层次化地放置数据，来兼顾成本和高性能。 CPU 原则 云上 A 个 CPU 计算 B 秒和 B 个 CPU 计算 A 秒（A * B = B * A）的成本相同。因此，云原生文件系统的计算任务应该尽量并行起来，这样可以在尽可能短的时间内完成任务。 类似于云存储的空间，云上的 CPU 数量也很容易扩展。云原生文件系统应该按需地使用 CPU，但也需要注意根据负载的变化对之前扩容的 CPU 数进行缩容，来控制成本。 由于云存储可以在计算节点间共享，可以适当的将与文件系统相关后台任务从计算节点分离出来，让计算节点的 CPU 资源更多地用于计算任务。 云服务中 […]

by ·0 Comments

MinIO 是一个用 Golang 编写的对象存储 server 开源实现。s3fs 是一个基于 FUSE 框架的以 s3 存储服务作为后端并导出 POSIX 文件系统挂载的开源实现。 本文首先基于 MinIO 搭建一个简单的对象存储服务。然后进一步借助 s3fs 将这个对象存储服务挂载为一个文件系统目录。 搭建 MinIO 对象存储 安装 Minio go install github.com/minio/minio@latest 启动 mkdir minio_dir minio server minio_dir CLI 操作 curl https://dl.min.io/client/mc/release/linux-amd64/mc \ –create-dirs \ -o $HOME/minio-binaries/mc chmod +x $HOME/minio-binaries/mc export PATH=$PATH:$HOME/minio-binaries/ # 设置 alias，之后就可以将 myminio 作为第一级目录操作了 mc alias set myminio […]

by ·0 Comments

本文以我的视角对 ublk 进行了最基本的分析，希望也为你带来帮助。 ublk ublk 是一个 6.X 内核全新的实现用户态块设备驱动的内核框架，之前的类似框架还有 TCMU、vdpa-user (VDUSE) 和 NBD。ublk 框架中，一个额外的 ublk Server 用户态进程作为 ublk 块设备的服务后端，实现了主要的存储逻辑。区别于其他用户态块设备框架，ublk 采用 io_uring 作为内核于用户态通信的传输机制。ublk 架构图如下： 使用 ublk 框架，内核会多出几种设备，包括一个唯一的 ublk_ctl 设备，多个名为 /dev/ublkcN 的字符设备，以及同样数量的 /dev/ublkbN 块设备。其中， 块设备是实际的存储服务设备，可以格式化文件系统或者作为裸设备使用，这也是 ublk 存在的最终目的； 字符设备是 ublk 框架的数据面接口，主要被用户态 ublk Server 进程用于与内核通信，处理块设备的实际 IO 请求； ublk_ctl 设备(/dev/ublk-control)则可以看作的是 ublk 框架的控制面通道，ublk Server 通过请求 ublk_ctl 设备来创建出多对字符设备和块设备， 类似于其他用户态驱动框架，ublk 为了方便用户态 ublk-server 的开发，也提供了用户态 SDK […]

by ·1 Comment

Persistent Memory (pmem, PM) 是很特殊的设备，它既是内存接口，又有非易失的存储特性。因此：作为内存，它即面临内存所特有的cache coherence等问题；作为存储，它也面临外存系统所特有的崩溃一致性、持久化等问题。 因此，构建一个基于PM的存储系统也所要考虑的问题是比较多的。近年来，学术界大量文章都在关注PM存储系统或者PM编程模型，比如PM感知文件系统、PM KV存储、PM事务框架等。 本文分为持久化、原子性和崩溃一致性三小节，讨论了PM系统编程的一些必须注意的点。文章整体基于我之前所写调研综述的相关部分，并进行了精简和修改。本文参考了很多文章并加入了自己的理解，若有问题，恳请指正。 1. 持久化 (Durability) 然而，对PM的store操作后并不能保证数据肯定存储到PM上，这是因为CPU和PM之间还有几层cache，要保证持久化，我们需要用flush / fence相关的指令。 当使用PM时，CPU对内存的store操作可能会暂存在硬件管理的cache或者write buffer中，若用户不强制刷cacheline到内存，无法保证store操作的数据何时写到内存中。在原来的情况下，内存为掉电易失的DRAM，所以刷或者不刷cacheline只可能牵扯到系统的性能，而不会影响系统的正确性；但是在使用PM时，由于持久化的存储是我们的目标之一，我们就要额外注重数据持久化的时机，以进行更精确的控制。 在使用块设备时，类似的问题同样存在。写操作一般会被缓存到系统的page cache中，因此需要用户调用fsync等函数来进行磁盘同步，让数据真正持久化地存储到磁盘上。解决PM cache数据写回的问题和块设备同步磁盘问题的思路是类似的，只不过方法不同。如下图，在x86平台中，当数据离开CPU cache进入PM或者进入电容保护的持久区(虚线框)，便意味着数据已经被持久化，因此只要使用将数据刷出cache并写回PM的指令，就可以保证相应数据持久化存储到PM了。 由于一般在使用PM时，是通过内存映射的方式进行的，所以使用操作系统实现的msync函数是可行的(msync和fsync具有相同的语义)。除此之外，用户也可以直接调用x86平台的cache刷新指令进行数据同步。 指令 说明 CLFLUSH 几乎所有CPU都支持，但没有任何并发性，串行地执行 CLFLUSHOPT + SFENCE 比CLFLUSH新，但是不是串行执行的，因此需要SFENCE CLWB + SFENCE 相对CLFLUSHOPT，可以在刷入PM后仍然让cache保持有效，局部性较好的数据使用此命令可以提升性能 NT stores + SFENCE 即non-temporal store，直接跳过cache的store命令，因此不需要刷新cache WBINVD 只能在内核模式用，将所有CPU的cache 刷入PM，一般不用，太影响性能 上表列出了其他的cache刷新指令，它们的行为各有不同，需要依据场景进行选择。除表中最后一项外，其他指令都是可以在用户空间直接使用的。在用户空间调用cacheline刷新指令的好处是不用切换到内核态，且用户能更清楚地知道哪块数据需要马上写回PM，所以用户的控制更精细，刷新指令的性能也要好于msync。但是，一些PM感知文件系统也需要msync的控制权，因为数据刷入PM若需要造成PM感知文件系统的metadata改变，那么用户空间使用cacheline刷新指令将导致PM感知文件系统metadata的不一致。所以用户程序应该仅在确保文件系统安全的情况下才使用cacheline刷新指令。 2. 原子性 (Atomic Updating) 这里的原子性指的是原子更新粒度(原子操作)或并发时的原子可见性(隔离性)，而非ACID事务的原子性。虽然ACID事务的原子性也是需要借助原子操作实现，这里的原子性更类似与ACID中的I(isolation, 隔离性)。 PM是内存接口，其原子性操作和内存类似，因此其访问原子性也和内存一样，在无锁保护的情况下， x86 平台上支持8、16 或 64 […]

by ·0 Comments

本文主要探索以mmap接口访问文件时，文件自身大小、mmap映射范围和我们所能访问区间之间的关系。主要通过几个小的实验程序来说明。 本文假定读者了解mmap可以作为文件访问的接口，若没有用过可以在Linux中直接man mmap看相关说明，或者去网上搜索其他资料。简单来说，文件的某一段经过mmap系统调用映射后会返回一个地址，这样我们可以像操纵内存一样操纵磁盘上的数据，因此”open +mmap+memcpy+msync “这套文件操作可以在很多的时候代替”open+read/write+fsync“这套文件操作。 但是相比write进行追加写的操作，被mmap映射的地址是无法做到改变被映射文件大小的，那么我们如果想改变文件大小怎么办？如果我们写的地址大于实际文件大小会出现什么情况？如果我们写的地址大于所映射的地址范围会有什么情况？ 通过两组简单的测试，我们可以探究这个问题： 测试1：”文件范围内, mmap范围外” 会产生SIGSEGV段错误 测试1是简单的情况，我们mmap映射的范围小于文件的实际大小，那么当我们访问在文件范围内但不是映射区范围内的地址时，会产生”segmentation fault”(SIGSEGV)错误！这很好理解，因为我们访问了非法的内存地址。 如下图，具体的，我们创建一个1 MB的文件，然后将其前512 KB用mmap映射，然后尝试访问文件第800 KB，第800 KB虽然在文件的范围内，但是不在映射范围内。结果是产生segmentation fault (SIGSEGV) 段错误。 +——————+——————+ file_testmap: | mmapped | not mmapped | +——————+——————+ 0 (KB) 512 ^ 1024 | we try to access here –+ (it will cause seg. fault) 程序1： #define _GNU_SOURCE #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> […]

by ·1 Comment

一个文件的长度和它实际所占用的磁盘空间很可能是不同的，这主要涉及到稀疏文件(sparse file)和文件打洞(hole punching)的概念。这两个特性需要操作系统和文件系统的支持，目前Linux的ext4、XFS等文件系统都支持这两个特性。 稀疏文件 (Sparse File) 了解系数文件最直观的例子是，创建一个文件，然后用lseek定位到较大的偏移量，在这个偏移量实际写一些内容，这时实际占用的磁盘空间很小，但文件的长度却比较大。比如： #include <fcntl.h> #include <assert.h> int main() { // 打开两个文件file_normal和file_sparse int fd = open(“file_normal”, O_RDWR|O_CREAT, 0755); int fd_sparse = open(“file_sparse”, O_RDWR|O_CREAT, 0755); assert(fd != -1); // 一个从0写入3个字节，一个从1000偏移写入3个字节 lseek(fd, 0, SEEK_SET); lseek(fd_sparse, 100000, SEEK_SET); write(fd, “ABCDEFG”, 3); write(fd_sparse, “ABCDEFG”, 3); close(fd); close(fd_sparse); return 0; } ls的-s选项可以在第一列打印出文件所占的磁盘空间： zjc@~$ ./sparse_file zjc@~$ ls […]

by ·0 Comments

Consistency这个词在计算机各领域用的很多，比如分布式系统、体系结构和存储系统等等。本文只探讨存储系统crash consistency。Crash Consistency问题在存储系统中都会存在(数据库、文件系统、dedup系统 …)，即系统遭遇断电、崩溃等情况时，相关联的数据没有全部持久化可能导致的不一致。本文以文件系统为例进行说明，所有内容基于自己对相关资料的理解，如有错误，恳请指正！ 崩溃为什么会导致不一致 下表整理自我的OSTEP笔记[1]，我们假设了一个有data和inode、bitmap两种metadata的简单文件系统，下表给出了一些可能导致不一致的情况，其中N表示断电时没有写完，F表示断电时已经完成： 多种metadata之间的一致性通常最麻烦：如上表的inode和bitmap，他们之间存在相同冗余信息（bitmap可以从inode推导出，但是这个推导是要遍历所有inode的，bitmap的作用就是用冗余的信息换取性能），并且由于并非在一个磁盘块，无法原子地同时更新，所以如果掉电时只有两者之一成功更新了，那么它们之间相同的信息便存在了不一致。metadata和data之间也存在不一致的情况：如上表中，若两种metadata都更新好了，但是data写到一半掉电了，那么下次开机后根据metadata读data时就会读到坏的数据，因此可以称为不一致。 追究其根本原因，是存储系统中底层硬件的一次磁盘I/O(512字节)，无法保证上层的一次请求的相关联的所有data和metadata的原子写入；反过来想，如果上层的每次请求中data和metadata都连在一起且小于512字节，那么就不用额外的一致性机制保证Crash Consistency。 保证一致性的方法–以WAL为例 由于硬件或者底层的原子写单元和上层存储系统一次请求所涉及的更改不匹配，所以我们只能在上层存储系统中用额外的手段保证crash consistency，常用的方法有: WAL(Write ahead logging, 也叫logging或journaling), CoW(Copy-on-Write, 也叫shadow paging), log-structuring, ordered write, soft updates等等。本文只简单举例说明一下WAL这种最常见的方法如何保证crash consistency： 比如，WAL为了保证bitmap和inode等不同种metadata之间一致性，在更改metadata时，一定要先将这些metadata写入到磁盘上的log区域，然后再对目标位置的metadata进行更改，这样，如果系统在写log时掉电了，原始的metadata没有影响，如果在写原位置metadata时掉电了，又可以在开机时从log进行重做(所以文件系统中的WAL类似于DBMS中的redo log)。 不同人对一致性有不同的认识 对于一个对任何事要求都很低的人来说，也许只有文件系统由于crash而被破坏了、不能再正常使用了才是不一致；他可能认为仅仅metadata和data的不一致可能并不算不一致，因为文件系统还会正常工作，只是被FS服务的用户或应用得到了错误的数据，谁叫他把电线拔了呢?。因此对一致性的定义、对一致性强弱的要求也是因人而异，因系统设计目标而异的。 比如，ext4是一种基于WAL的文件系统，具体提供了3种logging模式：journal, ordered(default), writeback。这三种方法对一致性的强度依次减弱，可以帮助我们理解为什么不同人、不同场景需要不同强度的一致性：journal是把所有data、metadata先进行logging[2]；ordered是用ordered write的方法保证data和metadata的一致性，用logging保证不同类别metadata之间的一致性，ordered write指但是先写data完成，再写metadata的顺序，data因此也不用进行logging；writeback则不管data和metadata的先后顺序，data也不写log，可能刚刚提到的要求很低的人和对性能要求更高的人才会用这个参数吧。 摘自kernel文档[2] data=journal All data are committed into the journal prior to being written into the main file system. Enabling this mode […]