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

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 […]

by ·0 Comments

本文是对《A Primer on Memory Consistency and Cache Coherence》这本书前一半内容的记录和理解，主要涉及memory consistency model。 1. 引言 对于多处理器共享内存系统来说，consistency和coherence都关注的是共享内存(shared memory)及cache的正确性问题，而人们把这个问题拆成两个方面是为了更好地将这个复杂问题分治解决。 1.1 Consistency 一般需要被详细讨论的是多核(或线程)共享内存(shared memory)的consistency模型，因为单核单线程问题相对简单直观。内存consistency模型规定的是：多线程同时进行load/store操作时，怎样的执行顺序是对的，怎样是错的。比较简单直接的consistency模型包括sequential consistency、TSO(total store consitency，x86使用)等。 1.2 Coherence 本文主要记录与consistency有关的内容，但因为consistency的实现与coherence有关，所以要简单介绍下coherence及其与consistency的关系。 虽然coherence的中文也翻译成“一致性”，但coherence这个词通常跟在cache后面，即缓存一致性(cache coherence)，解决缓存一致性问题的方法也被称为缓存一致性协议(cache coherence protocol)。那么共享内存系统的cache为什么需要coherence协议保证共享内存系统正确性呢？这是因为cache一般分为L1、L2和L3等很多层，L1等比较高的层级中，cache是每个核所独占的，一般只有L3、memory等层级才是共享的。在每个核独占的层级中，可能出现统一内存地址的数据在不同独占cache中数值不一样的情况，这时cache的状态可以称为incoherent。通过无效化等coherence协议，可以保证多核系统cache的正确性。 1.3 Consistency 和 Coherence的关系 对于sequential consistency和TSO等比较简单的consistency model来说，保证了coherence的cache可以被看成一个“黑盒”甚至对consistency model透明，黑盒中有cache实现有保证cache使用正确的coherence protocol，而consistency更关注程序(或处理器核)的访存顺序。因此对于简单的consistency model和coherence protocol来说，两者是解耦的。 1.4 一个小例子 如果上边几段不易理解，作者在书中用一个例子解释了这两个名词的基本含义，简单记录如下，有改编： consistency的例子 设想有三个人，计算机体系结构课程老师、教务处网站管理员和上课的学生，老师最开始在教务处上登记了上课的地点是152教室，但是开学第一节课后发现选课的人太多了152坐不下，于是准备下节课开始换到更大的252教室，于是老师先①找教务处网站管理员说“请你把网站上我课的教室信息改到252（要求①），随后通知学生们去教务处网站查询下节课的上课地点（要求②）。这就产生了一个问题，网站管理员可能是第二天才更新的网站，而学生是接到老师的通知马上重新查看了教务处网站，因此学生下周又来到了152教室，老师的计划和最后的结果出现了不一致情况。 问题就出在老师的做法无法保证学生在网站被修改之后再去网站查询。要想保证学生查到正确的信息，一种简单的办法就是保证管理员的确更新了数据，然后再通知学生们。这种简单的办法就可以称为一种一致性模型。 我们把这个例子对应到实际的内存系统中，给管理员和学生要做的两件事（要求①和②）可以分别看成一条store命令和一条load命令，目标都是教务处网站上老师的教室号，这个目标可以看成同一块内存地址，因此对同一内存地址执行的store和load命令是否可以调换顺序(管理员在学生查询才修改了网站)，调换顺序后是否破坏了程序的正确性，就是内存一致性模型memory consistency model所负责的。也就是说，出现上述情况算不算错，应该是当前的一致性模型所判断的：相对于我们每个人心中直觉上的一致性模型，这种走错教室的情况肯定是错了，但是对于一个性格怪异的老师，也许他觉得这样也是对的，比如他可以找他的同事帮他上152教室的课，他自己上252教室的课，也正因他如此怪异，所以他最开始联系网站管理员时也遵循了他心中的怪异的一致性模型，没有等网站确实修改就给学生们发了查询教室的通知。 coherence的例子 紧接上个例子，与之不同的是，很多学生在最开始选课的时候就把《体系结构》这门课的教室152记在了自己的小本本上，但是后来，管理员将网站上教室信息改成了252。虽然学生的小本本上和教务处网站上的信息应该是同一个信息，应该是一样的，但是这时两者一个152，一个252，这就出现了incoherent的情况。 在内存系统中，学生的小本本就相当于cache，而教务处网站相当于memory，学生将memory中的某个值拷贝到了cache中，当memory被其他人更新时，学生自己的cache就应该同时立即处于无效的状态。这里出现incoherent的原因就是没有一个cache coherence protocol来保证cache的正确性。比如，一个简单的coherence protocol可以这么干：在网站更新后，老师挨个找到每个学生，把他们的小本本记的152划掉?，无效化协议就是这种思想。 2. […]