9月15日学习笔记

18.2.2 EXT4文件系统支持大容量存储

EXT4：支持大容量存储、快速恢复异常状态

对于大文件而言，Ext2/3访问开销是非常大的

EXT4设计思路：extent，一段连续的储存块

18.2.3 EXT4文件系统-支持恢复异常

crash-consistency problem

解决方法1：File System Checker（fsck）

superblock：文件系统大小大于已分配的块数

Free Blocks：bitmap v.s. Free blocks

Inode state/links：有效的类型字段/链接计数

Duplicates：两个inode指向同一个data

Bad blocks：指针显然指向超出其有效范围

Directory：“.”和“..”是头两项

局限性：太慢

解决方法2：日志Journaling（write-Ahead logging）

从数据库管理系统的世界中窃取一个想法

最早（1987）在Cedar文件系统中出现

出现在EXT3/4，JFS，XFS，NTFS等

基本思路：更新磁盘时，在覆盖相关结构之前，先写下一点日志（在磁盘上某个设定好的其他位置），以描述要执行的操作

Data Journaling：TxB：transaction开始；TxE:transaction结束;logical logging:中间3块数据，transaction写到磁盘后，更新磁盘，覆盖相关结构（checkpoint）

五块disk写操作可能会乱序，也可能出现信息不完整

拆成两个transaction，确定db一定写进去，再写TxEtransaction

Journal write、Journal commit、Checkpoint

恢复（Recovery）：在此更新序列期间的任何时候都可能发生崩溃，如果崩溃发生在将事务安全地写入日志之前，如果崩溃是在事务提交到日志之后但在检查点完成之前发生

不足之处，写的太多，太慢

优化：两个思路

思路一：批处理日志更新，单个太慢，就做批处理

思路二：使日志有限：循环日志

思路三：日志超级块：journal superblock

新的更新过程

Journal write

Journal commit

Checkpoint

Free：一段时间后，通过更新日记账，超级块将交易记录标记为空闲

多次写的问题还是没有彻底解决

方法2：Metadata Journaling：进一步提高速度

我们什么时候应该将数据块Db写入磁盘？事实证明，数据写入顺序对于仅元数据的日记记录确实很重要，如果在事务（包含I[v2]和B[v2]）完成后将Db写入磁盘，这样由问题吗？有问题，在准备写Db时，出现了crash，恢复的时候，Db没有了

新的更新过程：

Data write

Journal metadata write

Journal commit

checkpoint metadata

Free

通过强制首先写入数据，文件系统可以保证指针永远不会指向垃圾数据，既保证了速度，也保证了安全可靠

18.3 ZFS文件系统

Zettabyte File System

Solaris系统中出现

The last word in file system

管理简单，事务一致性，端到端完整性，可扩展性

存储池，不再使用文件卷，类似VM

基于对象的事务系统：

校验和：分层次

特征，容量128bit，文件系统内部实现了数据错误的检测与更正

多个文件系统可以共享存储池

在池中可以共享IO通道

everything is copy-on-write

everything is transactional

RAID-Z

条带化