文件系统 - 蜗窝科技

F2FS技术拆解

作者：OPPO内核团队发布于：2020-1-31 20:26 分类：文件系统

F2FS (Flash Friendly File System) 是专门针对SSD、eMMC、UFS等闪存设备设计的文件系统。由三星工程师Jaegeuk Kim于2012年10月发布到Linux社区，并于2012年12月进入Linux 3.8 内核主线。和UBIFS、JFFS2等文件系统不同，F2FS并不直接面向裸NAND闪存设计，而是和其他通用文件系统一样基于块设备层接口实现。既然如此，为什么说F2FS是针对SSD、EMMC、UFS等闪存设备设计呢？另一方面SSD、eMMC、UFS等拥有FTL（Flash Translation Layer）的闪存存储已经对外提供了通用块设备接口，是否真的需要针对性地设计一个文件系统呢？F2FS的“Flash Friendly”体现在哪些方面呢？请跟随本文对F2FS的设计实现做详细拆解，揭开F2FS与FTL“剪不断理还乱”的“爱恨交织”。

阅读全文>>

标签: F2FS

评论(7) 浏览(18569)

文件系统和裸块设备的page cache问题

作者：阿克曼发布于：2018-4-28 10:16 分类：文件系统

普通文件的数据可以保存在它的地址空间中，同时直接访问块设备中此文件的块，也会将这个文件的数据保存在块设备的地址空间中。这两份缓存相互独立，kernel并不会为这种非正常访问同步两份缓存，从而避免了同步的开销。

注：本文代码基于linux-3.18.31，此版本中块缓存已经合入页缓存。

阅读全文>>

评论(9) 浏览(13443)

为什么会有文件系统(二)

作者：驴肉火烧发布于：2017-6-27 21:06 分类：文件系统

距我将全套盗墓笔记成功保存在8MB空间里已经过去了19天58分钟32秒，我渐渐发觉更高、更快、更强的绝不限于奥运精神，也充分体现了人类贪婪的本质，无尽的需求催生出这光怪陆离的大千世界。

就在今天下午，我得到一个通知，要么继续使用连续的存储空间，但是只能有4MB，要么去使用不连续的存储空间，总量可以仍然是8MB，那一刻，我的内心反而是平静的，因为我知道，这就是现实，一个不够优秀的系统是无法满足各种刁钻的需求的，并且我并不想丢掉一半的盗墓笔记，所以我必须使用不连续的存储空间，一个不算坏的消息是，就算是不连续，但是每块最小也有2048字节，并且连续的存储空间是2048字节对齐的，还有什么好说的，撸起袖子加油干，这很2017。

阅读全文>>

标签: 文件系统

评论(13) 浏览(12333)

为什么会有文件系统(一)

作者：驴肉火烧发布于：2017-1-17 20:56 分类：文件系统

Linux发展到现今，在fs目录下我们可以看到形形色色的文件系统，眼花缭乱的同时首先需要回答的问题是，为什么会有文件系统这个东西呢？我想如果能搞清楚这个问题，会帮助大家更好的理解文件系统，那么我就尝试着来模拟一次文件系统的演进过程，于是，我们来到了那一天，那天之前，人们还没有文件系统的概念。

友情提示 : 下面将在荒诞的场景下演进人类合理的诉求

神说，要有光，于是，光照大地

神说，要有风，于是，风动四方

神说，人类要记住神，于是，有了传说

神说，怕你们忘了，得记下来，于是，有了文字，信息被存储在石板上，竹片上，纸张上，硬盘里，flash中

当信息能存在硬盘中的时候，人类如获至宝，如此大的存储量，我们能装下全世界图书馆的馆藏，于是，我们想先放一套盗墓笔记进去。

好嘞，于是，我一个字一个字的将精彩的内容顺序存储在硬盘中，终于，全套的盗墓笔记被存储在硬盘中了，还没来得及高兴，就傻眼了，我不想看秦岭神树，怎么办，这并难不倒我，略加思索，就能想到解决方案，因为是顺序存储的，从开始的地方一直读下去，当恰好跳过秦岭神树章节内容的时候，就做一个标记，记录已经跳过的字节数，下次再看的时候，就直接读到硬盘对应的位置即可，经过一番努力，我找到了并把这个字节数写在了一张纸条上，以便下次可以直接读取，避免一次次的遍历。

后来，我开始有点不耐烦了，因为这张纸条里面的内容越来越多，比如最后一章的位置，终极第一次出现的位置等等，有时我甚至记不住我需要寻找的标记是否在纸条中了，终于有一天，这张纸条丢了，我只能呵呵并且从心底认为，仅仅是顺序存储无法满足我的需求，我需要管理这些内容。

我想，最起码我需要能把全套的盗墓笔记分为8本书吧，只要根据书名，比如邛楼石影，我就立刻能找到对应的内容，我立刻想到了最简单的解决方案，仍然使用顺序存储，只不过在内容录入的时候，给每本书分100MB的存储空间，这样我如果想看第7本，那么直接从600MB偏移开始即可，那么一套盗墓笔记只需要800MB就可以存储，但是，我很快又有了一个更优的方案，在每本书的100MB可用空间内，再进行细分，给每章节进行划分，假设每本书有50章，那么每章节就是2MB空间，这样每章节按照2MB对齐，我要找第6本书的第30章节，就是(500 + 29 * 2)MB 偏移，我甚至都有点洋洋自得了，简单的设计一下就可以再也不用依赖那张小纸条(已遗失)了。

但是，很快我又遇到了新的挑战，因为这块硬盘不是我的，开始说好的800MB没有了，我被要求只能使用8MB来存储全套的盗墓笔记，原先的设计继续使用，每章只能分到20KB，这样有些内容多的章节会越界，而有些内容少的章节又不够饱满，那些没有被利用起来的空间此时显得的是那么的珍贵，于是我开始了小心翼翼字斟句酌的重新设计。

看起来，顺序存储是最节约空间的，那么只有将小纸条(已遗失)的内容也存储在硬盘中了。于是，喝下一罐可乐后，我发觉将章节抽象成一个章节类是一个不错的注意，每个章节是该类的一个对象实例，类成员包括章节名称，章节起始位置，章节字数，每个对象都64字节对齐，这样400章的索引信息只需要25KB即可完成存储，我大大方方的将全部的章节类对象存储在8MB的前32KB区域，后面剩余的全部顺序存储内容，就这样，随着需求的不断增加，我的设计也渐渐开始有文件系统的影子了，尽管我并不知道，但是一切就这样发生了，是那么的自然。

原创文章，转发请注明出处。蜗窝科技，www.wowotech.net

标签: 文件系统

评论(2) 浏览(10860)