Log-Structured 文件系统 ：1

前面我们讲过B树，B树是目前最常见的一类存储引擎，包括mysql和postgresql都广泛使用。b树类存储引擎有一个缺点：sequential write性能很差。比如说MySQL的innodb存储引擎，数据保存在b树的叶子节点上，更新数据时，索引也需要相应变动，于是B树就会进行重建，这要消耗时间。尤其是连续写入随机内容时，每插入一个，b树都会重构一次（不考虑write buffer的情况下，实际上情况会好很多，但是相比Log-Structured 文件系统，在这一点上性能差距还是很大），而且重构的幅度有可能会很大，这种时候性能是很差的。

任何设计都是有取舍的。 B树存储引擎在索引建的好的情况下，查询效率很高，但是随之带来的，更新数据会带来索引的同步更新，这是B树存储引擎需要承受的。这篇文章要讲的Log-Structured 文件系统，又是另一种思路。

简介

最先提出Log-Structured 文件系统（以下简称LFS）这个概念的是 Mendel Rosenblum，他还是vmware的创始人。

LFS的核心理念如下：write sequentially，永远不overwrite数据。按照顺序这么一直写下去，知道把文件写满。

在b树类存储引擎中，更新分两步，第一步需要先找到原来数据的位置（这一步叫做seek），然后才能进行更新，而且更新之后，B树的结构可能还需要重构。这在Log-Structured 文件系统就不存在，因为这里全部都是append操作，无需seek，也无需重构。更新一个文件 ，不是直接改变原文件，而是创建一个该文件的最新版本。

注：这里的”文件”，与其说文件，不如说是一个block。每个block的大小是一样的。那么如何通过block组成文件呢？文件就是很多block的组合起来的，所以文件中其实就是保护了这些block的位置等信息。

预备知识

inode

inode 全称index node,是unix风格文件系统的一种数据结构，用于描述文件系统对象（比如文件、目录）。每个inode存储着相应文件系统对象的属性（比如创建时间、权限信息等），以及文件系统对象对应在disk上的block的位置。

如上图，一个inode可能会指向多个block。

在传统文件系统中（FFS），一个文件或者一个目录就对应着一个inode，这个inode，也就是代表了它的在内存中的address，需要查询文件数据的时候，先通过这个inode address获取到文件属性和数据数据在disk上的位置这些信息，然后获取真正的数据。

write buffer

前面我们稍微提到过write buffer，MySQL的设计者很聪明，对每一个更新操作，不会直接更新disk上的数据，而是当更新操作积累到一定数目，或者到了一定时间节点的时候，批量地更新，这种效率要高很多。事实上，几乎所有的文件系统都会buffer write操作，因为这可以提高写的效率。但是，这个buffer又不能太大，因为文件系统很重要的一点就是一致性，如果buffer太大，当出现系统崩溃的时候，就会丢失数据。

设计要点

先明确一点，LFS的目的是什么？是解决B树类存储系统存在的写性能问题，实现途径是write sequentially。

LFS建立的假设前提：file被缓存在内存中，增加内存大小会提高read命中率；于是，disk进行的基本上就都是写操作了。

这个topic的内容很多也很杂，这篇先写到这里。总结一下要点：LFS存在意义是提高写性能，实现方式是write sequentially。

关注我的微信公众号