系统架构学习日志2-Log structured vs Journaling File System

这篇日志的讨论主要是围绕以下两篇文章:

1. M. Rosenblum, J. Ousterhout. "The Design and Implementation of a Log-Structured File System", ACM Transactions on Computer Systems 1992

2. V. Prabhakran, A. Arpaci-Dusseau and R. Arpaci-Dusseau. " Analysis and Evolution of Journaling File Systems", Usenix Annual Technical Conference, 2005

Log-Structured File System (LFS) 

首先是1992年这篇文章，首先提出一种基于log的文件系统。这里有个背景知识要说一下，传统的文件系统是把文件系统的元数据（meta-data) 和实际数据存储块（disk block）域分开放的。meta-data 也就是描述disk block的数据结构，linux
ext3 文件系统里的inode就是一种meta-data的实现。如果meta-data 被存在了 sector#3上，而 要写入的disk block存在 sector#190那里，那么更新完sector#3后，硬盘臂就要进行寻址（seek），找到第190号sector
才能继续写数据。

大家知道，seek是很费时的，因为硬盘大都是机械运转的，所以当你写一个文件需要几个次寻址、而且寻址的范围很大时，写的速度是很快的，也就是有很大的overhead. 

所以，为了优化写速度（write speed），1992年的作者们设计了一种 log structure 的文件系统sprite LFS。注意，LFS的设计目标是加快写速度，他们并不管读速度，因为作者们的预见是，那时内存越来越便宜，越来越有可能是从cache里读的，所以读速度已经很快了，而写速度相对较慢，慢慢成为了瓶颈。

LFS 的设计是，所有的写操作都是存成一个log, 一连串的写操作就被存成一连串线性的Log, 存在一个circular buffer里。（问题：为什么是一circular buffer呢？）这样做的好处就是，写速度很快，你不用寻址，直接append在circular
buffer最后未写的block即可。

（回答: 为什么是circular buffer呢？根据维基，因为cirtular buffer 比较适合缓冲数据流，当把buffer里的一个元素拿走以后，它不用把所有的元素都挪一个位置 .

我只是不太了解，用了circular buffer 以后，到底是什么用的呢？它提供什么样的API呢？到底好用在哪里呢？

答：其实道理使用很简单，如维基上的 用 c 语言的实现，就两个read & write的操作 cbWrite() 和 cbRead() ，都只要对一个抽象的cb对象进行操作就行了，不用理会里面是怎样实现的，但是我只要知道，如果要使用circular buffer,  就要知道我们用它来，必须是要FIFO操作很频繁的情况，这样才会有所performance gain。在把数据组织成这种形式以后，它就是一种很高效的、可以用来做数据缓冲的数据组织形式!  一边是生产者，另一边是消费者，就是适合这种操作情况！）

）

写速度确实提高了，但是LFS带来了几个问题：

1. 一连串的写操作都被存成了线性的log, 而且是按时间先后排序的，也就是说你保存了一堆历史数据。本来新的写会覆盖写旧的写的，而现在新旧的写都 在了一起，如何去消除数据冗余？当这个circular buffer满了的时间，你如何去回收buffer里的空间? 

2. 那读速度呢？读速度会被影响多少？

根据维基，LFS 系统的设计其实并不符合实际，原因有二：

1. 在传统磁盘上，用LFS的设计真的很损读速度，拖慢到不可接受的地步，而且LFS在垃圾回收的时候把数据block 碎片化，不利于寻址，不利于seek time的提高。

2. 在flash-based的硬盘里，用LFS不会提高多少，因为写已经很快了，

(To be continued).