联合缓冲区缓存和日志记录层与非易失性存储器

1、联合缓冲区缓存和日志记录层与非易失性存储器摘要日志技术广泛应用于现代文件系统为他们提供高可靠性和快速恢复系统故障。然而,它减少了性能好的缓冲区缓存作为日志占大部分的存储写在现实系统环境。在本文中,我们提出了一种新的缓冲区缓存架构,贯穿到缓存和日志记录功能利用非易失性内存如PCM（相变内存）或STT- MRAM（旋转扭矩传递磁性随机存取存储器）。具体地说,我们的缓冲区缓存支持我们所说的就地提交方案。该方案避免了日志,但仍然提供了相同的日志效应通过简单地改变缓存块冻的状态。作为一个冻块仍然执行缓存的功能,我们表明,就地承诺不会降低缓存性能。我们在Linux上2. 6. 38实现我们的计划并且测量吞

2、吐量和该计划在各种文件I / O基准的执行时间。结果表明,我们的方案平均提高I / O性能76%,相比现有的Linux ext4（外在的）缓冲区缓存提升了240%并且没有任何损失的可靠性。1. 介绍 非易失性内存如PCM(相变内存)和stt mram(旋转扭矩传递磁RAM)被视为替代DRAM内存（动态随机存取存储器（Dynamic Random Access Memory）1 8。虽然目前由于成本不适合完成替换但非易失性存储器已成为一个可行的组件,可能被添加到当前的系统来提高性能9。临时的非易失性存储器解决方案在以支持超级电容器DRAM（动态随机存取存储器）的形式出现在服务器市场 10。作为非

3、易失性内存预计将为DRAM提供性能竞争力,同时保留非易失性特征。最近利用这些双重特征的研究产生了兴趣(1 - 8)。本文也探索了这些通过合并缓冲区缓存和日志记录层新的内存技术非易失性的特点。我们相信,我们所掌握的最好知识即我们的工作是第一个提出这样的一个团队。 在传统的系统,主存是易丢失的, 在系统突然崩溃时文件系统可能会进入一个不一致的和/或过时的状态 11。为了缓解这个问题,日志记录是一种记录更新到非易失性存储在一个短时间段为高可靠性和快速的系统恢复,是广泛采用现代文件系统12。然而, 由于其频繁的存储访问，日志是一个严重的阻碍了高性能。例如,最近的一项研究表明, 由于日志存储在移动主导交

4、通手持设备，同步写导致严重放缓的闪存存储13。在云存储系统,即使有一个共识,日志记录是必要的, 由于高成本的网络访问参与日志所以它不能部署 14。在这项研究中,我们提出一个新颖的缓冲区缓存架构,消除几乎所有的存储访问由于日志没有任何损失的可靠性由智能采用非易失性内存作为缓冲区缓存。乍看之下,仅仅采用一种非易失性缓冲区缓存似乎不足以提供高可靠的文件系统。然而,这并非如此,其中有两个需求所需的支持文件系统的可靠性:耐用性和一致性。一种非易失性的缓冲区缓存,即使在停电后只需,确保耐久性作为它维护数据。然而,一致性无法保证在系统崩溃仅仅提供非波动到缓冲区缓存。例如,一个典型的情况下,写操作需要两个数据

5、和元数据的更新,但更新后系统崩溃只有元数据。然后,数据的缓冲区缓存失去一致性,最终导致不一致的文件系统状态。 我们提出一个新的缓冲区缓存架构,称为UBJ(合并的缓冲区缓存和日志),。通过图1提供的功能解决了这个问题。我们的提交进程缓冲区缓存和原日志缓冲区缓存比较。日志没有频繁的存储访问。具体来说,我们建议改变就地提交更新的状态缓存块冻(即。、写保护)和管理它们作为一个事务权利在当前的位置。这个方案不执行另外的日志只是收获同样的效果只是通过改变一个状态。此外,随着块在冷冻状态仍然可以被用作一个缓存块,缓冲区缓存的有效性不恶化。图1显示了我们提交的进程缓冲区缓存与现有结合日志缓冲区缓存的比较。与之

6、前的工作最密切相关的是本研究也试图缓解日志记录开销采用非易失性内存文件系统和数据库管理(15、16、17)。他们提高性能通过添加非易失性内存作为一个单独的日志区或者作为一个写缓冲区日志文件。然而,在这些方案里,非易失性内存不能作为一个缓存功能,分别从缓冲区缓存保存。我们的方案是不同的,我们的日志记录功能智能的结合到缓冲区缓存架构,从而尽量减少额外的内存复制和空间开销。我们实现了一个原型的缓冲区缓存与就地提交在Linux中2 .6 .38。测量结果与各种存储基准显示我们的方案提高了文件系统的性能平均提高了76%,相比现有的把ext4设置为日志模式Linux缓冲区缓存提高了240%。本文的其余部分

7、组织如下。第二节探讨在写日志存储交通的影响。第三节我们在细节描述了缓冲区缓存架构和算法。在第四节,我们讨论缓存性能问题的方案。第五部分提出了一个简短的描述,讨论了实现实验结果的实现。第六节总结本文。2。分析存储写交通图2显示了一定数量的写交通从缓冲区缓存来存储当日志是采用相对于它不是为各种工作负载。如图2所示,当使用日志写交通大大增加;使用日志记录的平均数据存储是没有日志记录的2.7倍。当我们不使用日志记录，存储写道的发生只有当脏块从缓存中删除或当有一个明确的同步操作。然而,随着日志,有两个或更多的情况下,导致存储写道。第一种情况下,一个致力于日志区域发生。第二种情况是当检查点写更新的数据到不

8、变的图2。有日志的写交通和我们提出方案(UBJ)相对于当没有为各种工作负载使用日志。文件系统位置的重现，检查点是周期性的触发,也激活当空闲空间的大小在日志区低于某个阈值。正如我们所见,因为所有工作负载,的日志占相当大一部分存储写道,因此,它是一种性能退化的潜在来源。如图2所示,然而,我们的UBJ方案执行日志记录除了消除了大部分的存储写. .。3. 缓冲区缓存与就地提交在UBJ,缓冲区缓存和日志区共享相同的分配空间。每一块在这个空间功能要么作为一个缓存块,一个日志块,或一个缓存和日志块同时有双重功能的块。我们可以描述每一块状态作为一个三个组合的状态指标:冷冻/正常状态,脏/清洁状态,和最新/过时

9、的状态(参见图3)。冷冻/正常状态的区分是根据是否块是一个(普通的)缓存块或一个(冻)日志块。脏/清洁状态指示是从它进入缓存是否已被修改的块。最新/过时的状态指示块是否是最新版本。这最后的区别是十分必要的,因为对相同数据的多个块可能存在于缓冲/期刊空间。下面,我们使用这些状态州和这些状态之间的转换来描述图3状态图的一个在我们的计划UBJ缓存块的工作原理。该计划被描述为三种不同的操作:读/写操作,提交操作,和检查点操作。a .读/写操作写请求反应取决于块的状态。如果块是正常的,它只是更新。否则,也就是说,如果它是冷冻(日志块),一份是到复制一个新的位置和更新的数据写入副本。复制然后成为最新的,而

10、原来的变得过时。这允许登录数据保持安全与系统故障。另一方面读请求是被作用的，不顾块的状态和不会改变块的状态块。这是因为阅读数据不影响一致性的街区。b .提交操作作为事务管理、UBJ定期提交数据,改变正常脏块的状态冻脏块。这是通过保持和操纵交易保持为列表。有三种类型的事务如图4所示。第一个是一个运行的事务,维护正常的脏块列表,脏了之后,以前的提交操作。当提交操作是发布,这个运行的事务被转换为一个提交事务。此时,提交事务上的块是正常状态是就地提交(因此,名称是就地提交)只需将其状态转换为冻结状态。新块的写到达这一转换过程仅仅是添加到新的运行的事务创建下一个提交时间。在状态转换过程中,如果相同的数据

11、块被提交UBJ也检查,如果是这样,跟踪前面的块作为旧提交块。对于高效的空间管理,这些旧提交块可能会立即释放。当所有脏数据块在提交事务成为冻结状态,我们把事务的状态更改为一个检查点事务。检查点的事务维持在缓冲区缓存,直到他们通过检查点被反映到文件系统。系统崩溃时,他们用于文件系统恢复到一个一致和最新的状态。C.检查点操作检查点操作更新文件系统提交的数据。UBJ扫描检查点的事务列表和反映了他们自己在文件系统中固定的位置。当一个数据块发生多次提交,只有最后提交块设置检查点,以减少检查点开销。事务检查点完成后,缓存空间被冻块回收。在这个过程中,如果是最新的,我们使用它作为一个缓冲区缓存块通过改变其状态

12、为正常,清洁,和更新相关的元数据。另一方面,如果块是过时的,空间回收作为一个自由的块。图4.UBJ的数据结构当频繁执行提交操作时,以减少漏洞窗口的可靠性，检查点可以做更少当它并不直接影响系统的可靠性。然而,过度延迟检查点可能有负面影响。随着检查点间隔的增长,越来越多的缓存空间将被冻块占用，有效减少缓冲区缓存,它可能导致缓冲区缓存性能的退化。为了防止这种情况,我们计划触发检查点当冻块的数量大于某个阈值，这个阀值是用传统的日志记录。检查点通过页面也引发回收守护进程当从缓存中清除脏块。图5 我们UBJ方案和原始缓冲区缓存日志的比较表一 总结工作负载特征5 举例图5显示UBJ的工作与一个典型的缓冲区缓

13、存方案的比较。在这个例子中,提交和检查点周期分别设置为30 和90秒。块A的初始内容是D0。在时刻 10写请求修改块A的内容D1,并将它转换成脏块。20秒后,提交。为了维持提交，UBJ只是改变块A的状态为冻结状态，而一个典型的缓冲区缓存会招致写入存储。假设另一个对块A的写发生在时刻 40。UBJ此时复制块A到另一个位置A，然后将新数据写入位置块A。然后块A变得过时,而块A现在最新的。(我们量化同一数据有多个副本块的影响。)随后写在块A被执行当它被提交(在这个例子中，写在时刻50)，因此冻结（在时刻 60）。当检查点时间发生在时刻 90,UBJ只反映块A的最新版本,它的内容是D3,进入文件系统消

14、除不必要的写(D1和D2)。在检查点之后,块A占据的空间被释放,而块A的最新版本被重用作为缓冲区缓存数据块。在本例中,我们看到UBJ写入存储只有一次当有检查点时。当它提交或检查点时一个典型的缓冲区缓存方案每次生成存储写。这导致块的写最终被覆盖,不需要保存。在实际中,提交比检查点更频繁,减少存储写的数量可能会更多。E.系统恢复系统崩溃导致不一致问题,当数据可能仍然在缓冲区缓存部分更新,日志区域和文件系统。因此,在重启异常终止,UBJ经历以下步骤进行恢复。首先,检查运行的事务列表。这个列表是驻留在缓冲区缓存块,可能是部分更新。然而,由于这些都是未提交的数据,因此,没有体现在文件系统上,我们只是使这

15、些块失效。接下来,我们考虑提交事务列表。在提交事务之间发生崩溃时,提交事务列表可能会在部分提交状态包含一个混合的提交和还未提交的块。在这种情况下,当正常提交操作没有完成,当它运行的事务列表时UBJ只是以同样的方式使数据无效。最后利用检查点事务，系统状态是一致的。即使文件系统可能损坏当在执行检查点操作发生崩溃时，系统可以恢复到一个一致的状态只需重新运行所有检查点操作，当所有的检查点事务仍然驻留在缓冲区缓存。图6 缓存丢失率作为缓存大小的功能。4. 缓存性能正如我们计划保留日志块在缓冲区缓存,一个数据块可能占领多个缓存块,降低缓冲区缓存的空间效率。为了研究这种影响,我们比较原始缓冲区缓存即只用于缓

16、存的缓冲区的丢失率和没有日志块（BF-no）和UBJ，这些缓存和日志空间是合并的。此外,出于比较目的,我们也观察到的丢失率的假设方案,使用一半的内存空间分配专用缓冲区缓存和另外一半作为专门日志区。我们将调用这个方案缓冲区缓存与内存日志(BFJm)。这个方案实现就像传统的日志记录日志,除了这样一个事实:日志区不是存储在内存中,可能是存储在非易失性内存中。图6划出3个对文件工作台标准的缓冲区缓存方案的缓存丢失率，这个标准是一个代表性的文件系统标准。表1总结了本文文件工作台工作负载使用的特性。我们相对于I / O足迹改变缓存大小从0.1 到2.0。一般来说,由于缓存将同时容纳所有块引用的痕迹所以缓存

17、大小是1.0和无限缓存容量是相同的。然而,随着UBJ 和BF-Jm使用缓冲区缓存空间的某一部分日志区,1.0的缓存大小可能不足以容纳所有的请求。对BF-Jm投入总量的一半空间缓冲区缓存,另一半缓存大小2.0相当于无限缓存容量的日志区域。此外,监控UBJ性能下降最糟糕的情况下,我们延迟检查点的冷冻日志块直到他们选为受害者的缓存替换策略。结果如图6所示显示UBJ的缓存的性能的展示只有边缘BF-no退化，相比于BFJm的性能显著下降。更清楚地明白这一点,我们也在图7中划出一部分缓冲区/日志区被冻块占用当缓存的空间大小是0.7(70%)工作负载的足迹,这是UBJ和BF-Jm之间的性能差距最大。我们观察

18、到UBJ对所有工作负载的日志区使用缓冲/杂志的很大一部分空间，这导致读请求被服务通过这些冻块。如图8所示,大约16%到48%的碰撞发生在UBJ区域。相反，像BF-JM方案只致力于（非易失性）日志空间不能充分利用驻留在那里的数据。随着时间推移，图9划出了对文件服务器工作敷在的日志空间比。这图显示了UBJ日志空间动态的改变根据工作负载的进展。（其他工作负载的结果是没有显示的，只是显示类似的动态行为。图10 吞吐量和文件工作台工作负载的执行时间图11 当文件集的大小是不同的IO空间吞吐量 图12 当事务数量是不同的邮戳吞吐量。5. 性能评估A. 实现我们在Linux 2.6.38 实现了一个UBJ原

19、型，我们把我们的方案与ext4原来运行在Linux(BF-ext4)的比较。我们设置ext-4的日志选项为日志模型，记录了数据和元数据，,提供和UBJ相同的一致性语义。根据常规配置,对所有方案的提交时间设置为5秒。检查点被触发，当4个日志区被填充满或者距离上次检查点时间过去5分钟.为了更好的空间效率,我们采用早期回收政策释放旧版本的冷冻日志块,也就是旧提交块,最近提交版本时立即生成相同的数据块。我们的实验平台由英特尔酷睿i3 - 2100 CPU 运行在3.1 Ghz和4 GB的DDR2 - 800内存组成。虽然我们的设计假定非易失性内存PCM或STT-MRAM等还没有商业化,我们只是使用的一

20、部分DRAM作为缓冲/日志空间。我们测量的性能有三个代表存储基准:Filebench（工作台）18,IOzone（IO空间）19,和邮戳20。B.实验结果图10显示了UBJ的执行时间和吞吐量和 BF-ext4 对工作台工作负载的比较。如图所示,UBJ在所有工作负载执行比BF-ext4要好。UBJ的执行时间和吞吐量平均比BF-ext4高30.7%和59.8%。Varmail在执行时间和吞吐量的性能改善是4个工作负载中是最大的，分别是60%和240%。如此大的改进背后的原因是,varmail包含大量的写请求,从而引起频繁的提交(由于其小内存占用所以经常不执行检查点)。此外,varmail发出并发读

21、写请求。虽然我们方案计划没有一个明确的政策来提高读取性能,消除频繁存储缓解硬件资源的争用像内存总线和dma方式,通常导致提高I / O性能。甚至读密集型工作负载的网络服务器和代理,由于这个原因UBJ得到改善分别提高了23%和11%。对于文件服务器是一个频繁的写，我们的方案和varmail比较相对来说提高的比较少。这是因为大多数写请求在文件服务器是大量和顺序写入,导致频繁的检查点。图11显示了UBJ和BF-ext4对IO空间基准的吞吐量 。IO空间测量文件IO的性能通过生成特定类型的批量操作。它创建一个大文件,在该文件上执行的一系列操作。我们测量的性能有两个IOzone场景-随机写操作和顺序写,

22、不同的总文件集的大小从100 mb到300 mb。图中显示,UBJ在所有配置优于BF-ext4。具体来说,平均性能提高2.1倍。这种增强的来源是通过就地提交大量减少存储写道。还要注意当文件集的大小减少时UBJ相对于BF-ext4执行的更好。这是因为较小的文件集大小检查点完成较少导致减少存储访问。不像UBJ， BF-ext4对文件集的大小不太敏感。这是因为BFext4的性能主要是提交的数量,这是独立于文件集的大小。另一个观察,可以由IOzone是比UBJ更敏感对文件集大小的随机写道。这是因为随机写在很大程度上影响寻道时间作为随机访问招致大量寻求检查点将磁头移动到所需的位置的开销。图12显示了邮戳吞吐量基准。邮戳模拟电子邮件服务器并发执行读写操作。基准报告单独的读和写操作的性能数据。我们不同的邮戳交易的数量从2000到10000在1000个文件中,其平均尺寸是500 kb。如图所示,UBJ展示平均比BF-ext4的吞吐量搞109%。请注意,由于减少存储写道读操作的吞吐量也提高了。我们还观察到当减少事务数量是UBJ的性能得到改善。类似于IOzone,这是因为更多的UBJ