文件系统

咱们很快乐地发表 JuiceFS v1.1-Beta 版本正式公布啦！这是一个功能丰富的版本，带来了许多实用的新性能和改良。在这个版本中咱们新增了以下性能： 目录配额：为目录设置配额限度，管制其大小和文件数目录克隆：疾速地复制目录及其内容，节省时间和空间一键复原回收站文件：一次性地复原某段时间内所有被删除的文件，无需一一操作一键收集诊断信息：一键生成诊断报告，不便排查问题和反馈意见疾速查看用量信息：疾速查看存储空间和文件数的统计信息此外，咱们还新增了一个元数据引擎 FoundationDB，一个反对分布式事务的 Key-Value 存储。 本次版本，共有 57 位社区贡献者参加奉献了 726 次提交，感激每一位的付出。 上面，咱们将具体介绍这个版本的新性能和变动。 目录配额配额能够用来限度文件系统中存储空间的最大可用量，避免因个别用户占用过多而影响整个零碎的稳定性。在之前版本中，JuiceFS 只反对文件系统级别的配额。这样一来，当这个文件系统被多用户共享应用时，管理员就无奈无效地管制每个用户的使用量。因而，在 v1.1 版本中，咱们为 JuiceFS 减少了目录配额的性能。具体来说，管理员能够依据须要为任意目录设置一个配额阈值（硬限度），之后如果此目录的使用量达到或超过该阈值，任何试图新建或扩大文件的申请都将失败，直到用户删除局部已有文件或管理员进步配额阈值。另外，为目录设置配额还有一个益处，就是能够让 JuiceFS 跟踪并记录它的应用状况，并在须要时疾速获取此目录及其子目录下所有文件的用量统计信息。 目录配额的治理须要借助于新的 juicefs quota 命令，其设置参数与现有的文件系统配额统一，通过 --capacity <val> 来限度容量和通过 --inodes 来限度文件数。例如： $ juicefs quota set $METAURL --path /test --capacity 1+-------+---------+---------+------+-----------+-------+-------+| Path | Size | Used | Use% | Inodes | IUsed | IUse% |+-------+---------+---------+------+-----------+-------+-------+| /test | 1.0 GiB | 1.6 MiB | 0% | unlimited | 314 | |+-------+---------+---------+------+-----------+-------+-------+以上命令为 /test 目录设置了 1 GiB 的容量配额，且同时能够看到该目录下已使用量为 1.6 MiB。因为为目录新建配额时，须要递归统计该目录下以后的使用量，因而为已有的大目录设置配额可能须要期待较长时间。如果想查问某个目录的配额及其以后用量，能够应用 quota get 子命令，如： ...

明天持续与大家分享系列文章《50 years in filesystems》，由 KRISTIAN KÖHNTOPP 撰写。 咱们将进入文件系统的第二个十年，即1984年，计算机由微型计算机倒退到了桌面和机柜工作站， BSD Fast Filing System 退场。 回看第一篇： 1974-Unix V7 File System 晚期的 Unix 文件系统曾经体现得很好，但也存在一些显著的问题。这些问题在操作系统 BSD（Berkeley Software Distribution）中进行了许多修复。 BSD 起源于 20 世纪 70 年代末和 80 年代初，由加州大学伯克利分校的计算机科学系开发和推广。在 Leffler、McKusick 等人撰写的的书中《The Design and Implementation of the 4.3BSD UNIX Operating System》有所记录。 1984 年发表的一篇经典论文《A Fast File System for UNIX》中，能够找到更扼要、也更学术的探讨。该论文的作者包含 Marshall McKusick、Bill Joy（过后在Sun公司）、Samuel Leffler（过后在LucasFilm 公司）和 Robert Fabry。该论文提出了一个对 Unix 文件系统的从新实现计划，旨在晋升文件系统的吞吐能力、优化存储空间的调配和加强数据拜访的局部性。 The hardware在1984 年，4.3BSD 所针对的计算机是桌面和机柜工作站。这些机器具备 32 位数据寄存器和 32 位地址寄存器。 内部数据和地址总线的大小各不相同：晚期的 68k 系列 CPU 总线尺寸较小。 但在 1984 年，Motorola 68020 诞生了。它是首款提供残缺 32 位宽度总线的 68k 系列，集成了大概 200,000 个晶体管在芯片上。起初，68030 将本来独立的 MMU（内存治理单元）集成到了芯片上，而 68040 则将本来独立的 FPU（浮点运算单元）也集成到了芯片上。 ...

元数据是存储系统的外围大脑，元数据性能对整个大数据平台的性能和扩大能力至关重要。尤其在解决海量文件的时候。在平台工作创立、运行和完结提交阶段，会存在大量的元数据 create，open，rename 和 delete 操作。因而，在进行文件系统选型时，元数据性能堪称是首当其冲须要考量的一个因素。 目前支流的大数据存储计划中， HDFS 是应用最为宽泛的计划，曾经过十几年的积淀和积攒；以 Amazon S3 为代表的对象存储是近年来云上大数据存储的热门计划；JuiceFS 是大数据圈的新秀，专为云上大数据打造，基于对象存储来进行大数据存储。因而，咱们选取了这 3 个典型的存储计划 HDFS、Amazon S3 与 JuiceFS 社区版 进行元数据的性能测试。 测试方法NNBench 是Hadoop 中有一个专门压测文件系统元数据性能的组件，本次测试就是应用它来进行的。 原版的 NNBench 有一些局限性，咱们做了调整： 原版 NNBench 的单个测试工作是单线程的，资源利用率低，咱们将它改成多线程，便于减少并发压力。原版 NNBench 应用 hostname 作为路径名的一部分，没有思考同一个主机里多个并发工作的抵触问题，会导致多个测试工作反复创立和删除文件，不太合乎大数据工作负载的理论状况，咱们改成应用 Map 的顺序号来生成路径名，防止的一个主机上多个测试工作的产生抵触。测试环境测试区域：us-east-1 测试软件： emr-6.4.0，hadoop3.2.1，HA部署master（3台）：m5.xlarge, 4 vCore, 16 GiBcore（3台): m5.xlarge, 4 vCore, 16 GiBJuiceFS 社区版本：v1.0.0 JuiceFS 元数据引擎：ElastiCache，6.2.6，cache.r5.large 性能体现先来看看大家都相熟的 HDFS 的性能体现： 此图形容的是 HDFS 每秒解决的申请数（TPS）随着并发数增长的曲线，随着并发的减少，TPS根本出现线性增长。 S3 速度比 HDFS 慢了一个数量级，但它的各种操作的速度根本保持稳定，总的 TPS 随着并发数的增长而增长。但 S3 性能不太稳固，能够看到 Delete 申请在 100 并发下反而呈现了降落的状况，猜想可能和 S3 自身的负载无关。 ...

作为承载海量数据存储的分布式文件系统，用户通常须要直观地理解整个零碎的容量、文件数量、CPU 负载、磁盘 IO、缓存等指标的变动。 JuiceFS 没有反复造轮子，而是通过 Prometheus 兼容的 API 对外提供实时的状态数据，只需将其增加到用户自建的 Prometheus Server 建设时序数据，而后通过 Grafana 等工具即可轻松实现 JucieFS 文件系统的可视化监控。 疾速上手这里假如你搭建的 Prometheus Server、Grafana 与 JuiceFS 客户端都运行在雷同的主机上。其中： Prometheus Server：用于收集并保留各种指标的时序数据，装置办法请参考官网文档。Grafana：用于从 Prometheus 读取并可视化展示时序数据，装置办法请参考官网文档。Ⅰ. 取得实时数据JuiceFS 通过 Prometheus 类型的 API 对外提供数据。文件系统挂载后，默认能够通过 http://localhost:9567/metrics 地址取得客户端输入的实时监控数据。 Ⅱ. 增加 API 到 Prometheus Server编辑 Prometheus 的配置文件，增加一个新 job 并指向 JuiceFS 的 API 地址，例如： global: scrape_interval: 15s evaluation_interval: 15salerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093rule_files: # - "first_rules.yml" # - "second_rules.yml"scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "juicefs" static_configs: - targets: ["localhost:9567"]假如配置文件名为 prometheus.yml，加载该配置启动服务： ...

当初上课上的迷迷糊糊，最近我查阅了一些材料，将文件系统中的基础知识有逻辑的整理出来。 什么是文件？unix中的目录是什么？如何了解硬链接和软链接？（文件共享）目录中是如何检索文件的？文件的逻辑构造和物理构造？或者说文件再磁盘上是如何被组织起来的？闲暇文件的组织与治理？磁盘的组织与治理？什么是文件？提到文件，大多数人的脑子中必定首先浮现的是pdf、jpg，mp3等文件。他们的确是文件，然而你脑子中所想的只是文件的文件体，也就是文件真正的数据（一些二进制流）所在。 那么要对文件进行治理，只有这些数据不够，还须要一些形容信息（文件名、文件外部标识、文件存储地址、拜访权限、拜访工夫），这些形容信息能够称为文件阐明，也能够称为文件管制块（FCB）。 所以unix中的文件 = 文件体 + 文件形容信息。 上面思考一个问题： XV6和所有的Unix文件系统都反对通过零碎调用创立链接，给同一个文件指定多个名字。你能够通过调用link零碎调用，为之前创立的文件“x/y”创立另一个名字“x/z”。即便在windows中也能有创立快捷方式，将同一个文件重命名并存放在不同的地位。而两个文件拜访的内容确是截然不同的。所以，在文件系统外部，文件描述符必然与某个对象关联，而这个对象不依赖文件名。 那么这个对象就是大家熟知的inode（index node，索引结点）。inode是什么，间接拿inode的数据结构来看是最好不过的了。除此之外，零碎会为每一个inode调配一个惟一的编号。 inode的数据结构： 通常来说它有一个type字段，表明inode是文件还是目录。nlink字段，也就是link计数器，用来跟踪到底有多少文件名指向了以后的inode。size字段，表明了文件数据有多少个字节。不同文件系统中的表达方式可能不一样，不过在XV6中接下来是一些block的编号，例如编号0，编号1，等等。XV6的inode中总共有12个block编号。这些被称为direct block number。这12个block编号指向了形成文件的前12个block。举个例子，如果文件只有2个字节，那么只会有一个block编号0，它蕴含的数字是磁盘上文件前2个字节的block的地位。之后还有一个indirect block number（当文件数据过于大的时候，用于扩大，此处咱们不具体探讨它）从下面能够晓得，inode中存了文件体（也就是文件实在的数据）的地址，通过inode找到文件内容。这样一层封装，使得不同的文件名都能够映射到这个inode上来，从而找到文件数据。 可是，文件名去哪了呢？inode中的内容很像下面讲的文件阐明（文件形容信息），其实正是。不过恰好缺了文件名。而文件名和inode编号之间必然有一个映射表，这张表又在哪里呢？答案就在目录！ unix中的目录是什么？目录就是一个文件。 一下子可能无奈了解，还是从你的思维登程，提到目录你可能想到一个文件夹外部的构造。就大略这么一张图，也就是说目录外部应该包含一些文件（此处的文件指的就是个别的文件如下图中的mmap文件）和子目录（下图中的存储管理、IO、基础知识都还是一个目录）。 接下来就好了解了，目录是一个文件，文件体（数据）中存的就是这些文件/子目录的文件名和inode编号的映射表！ 也就是说，对于每个文件而言，其文件名和实在的数据是存储在不同的物理地位上的。 举个经典例子，通过门路查找文件的过程：/home/alex/main.py /能够了解为根目录，根目录因为是固定的，所以其inode的地位是零碎已知的。那么先找到root的inode的编号（此处须要阐明能够通过inode编号间接计算出inode的地址，具体计算形式不在此赘述），读取其信息，其那些文件体的地址，而后找到文件体，发现外面都是文件名/子目录名与inode编号的映射关系，逐个遍历文件名（之后在检索中还有其余形式，此处为线性检索）而后找到匹配的“home”，查到它的inode编号，获取其inode中的内容，而后找到实在的数据。以此类推，找到alex目录文件的inode编号，继而再找到main文件的inode编号。此时，main文件的inode中的指针指向的就是main.py实在的数据。 有一个十分乏味的景象，就是文件名是由其目录所存储的。而root文件没有上一级目录了，所以root是没有文件名，或者说是一个空的文件名，只用一个/示意。/home/alex/main.py能够了解为空/home/alex/main.py。 如何了解硬链接和软链接？了解了inode概念，再来了解硬链接就不要太容易了！ 硬链接理性的了解，就是为同一个inode取了一个新名字，这样新名字和旧名字对应的inode编号都是同一个文件。那么为什么要设计硬链接呢？当然是因为要共享咯！同时须要留神的是，在inode中有个属性叫做nlink，当有一个新的硬链接时，inode会将这个值加一，表明这个文件在被其他人共享。当删除这个硬链接时，inode会判断nlink是否为1，若为1，则表明是这个文件最初一个客人要把我删除，那么在删除硬链接的同时，数据也会被删除；否则，间接将nlink减一即可。 硬链接存在的问题：文件的创建者不能删除文件。因为文件被共享之后，只有文件的最初一个所有者能力删除文件。 此处思考一个乏味的景象，是我本人的揣测。为什么不间接将所有的文件形容存在目录文件中呢？也就是说能不能让目录文件中的目录项为文件名与文件形容（原先inode中存储的信息）的映射呢？这样就不要先通过文件名找到inode，再通过inode找到文件形容了。 考虑一下，如果此时呈现大量的硬链接，而且还是对同一个文件的，那么文件的文件形容就会被反复存储。（数据库中称之为传递依赖）那么将这些文件形容拆散进来，当做一个inode存储，在原表中搁置inode的编号。 引入软链接，能够解决上述的问题。软链接其实是存储了被共享文件的路径名，这个路径名能够是绝对路径也能够是相对路径。所以软链接的inode和被共享文件的inode不同，当通过软链接查找文件时，其实是先获取到被共享文件的路径名，而后循着这个门路查找文件。这样一来，若文件的创建者将文件删除，那么即便有着这个路径名也无奈查找到对应的文件。 同时，软链接也存在一些问题，就是每次都得通过门路逐层查找，开销较大。 目录中是如何检索文件的？首先解答一个问题，就是目录的构造是怎么的？咱们当初可能很好答复，应该是树状构造的。没错，然而目录构造最开始有单级目录构造、二级目录构造。再是树状构造，图状构造的。 单级目录构造就是将所有的目录项堆在一个表中。二级目录构造是依照用户分了一级进去，每个用户本人的目录项还是堆在一个表中。树状构造是对二级目录构造的推广，或者能够称之为多级目录构造。 检索文件的形式：线性表、哈希表。线性表之前曾经阐述过了，哈希表也就是散列存储，通过文件名间接输出到散列函数中即可失去inode编号。 未完待续...

问题发现最近在测试遇到一个问题，容器日志过大导致系统磁盘爆满，造成的影响就是该服务器的一些服务挂掉了。日志过大，解决办法就是删啊，间接定位到容器日志地位发现高达5G，三下五除二就rm了，然而依然显示磁盘空间已满，然而du -sh命令也显示文件夹下为空。通过共事百度得悉，容器日志不能间接rm，要通过cat /dev/null > {log文件}形式将日志删除。因为该文件被过程所援用，间接删除并不能擦除磁盘上的文件block信息，解决形式就是进行过程。明天就来复现一下并探索一下底层原理。 复现形式因为容器也属于一种过程，援用文件的形式并没有不同于其余一般过程，所以就应用一个简略的demo复现。 首先进入一个目录，以/tmp/testfile目录为例,能够看到我的服务器还有2G的残余空间 [centos@guozhao testfile]$ cd /tmp/testfile[centos@guozhao testfile]$ df -h .文件系统 容量 已用 可用 已用% 挂载点/dev/vda1 50G 49G 2.0G 97% /而后生成一个随机文件，再来查看残余空间，看到还残余1014M空间 [centos@guozhao testfile]$ dd if=/dev/urandom of=/tmp/testfile/delfiletest bs=1M count=1000记录了1000+0 的读入记录了1000+0 的写出1048576000字节(1.0 GB)已复制，8.31491 秒，126 MB/秒[centos@guozhao testfile]$ [centos@guozhao testfile]$ df -h .文件系统 容量 已用 可用 已用% 挂载点/dev/vda1 50G 49G 1014M 99% /启动一个程序，援用该文件，不退出过程 func main() { file, err := os.Open("/tmp/testfile/delfiletest") defer file.Close() if err != nil{ fmt.Println("open err :",err.Error()) return } time.Sleep(100*time.Minute)} 接下来删除该文件文件，查看磁盘占用状况，看到尽管文件删除，然而磁盘空间并没有开释。 ...

首发于我的博客网站(prajna.top) 欢迎大家前去交流，有pdf版本。 本文主要是从应用的角度出发，分别阐述操作系统接口，计算机语言，文件系统等背后的一些知识，规范，原理，设计思想，应用法门，让初学者对编码有一个整体的，全局的认识，有一个物理的视角，找到自己的起点。 前言写这篇文章主要是基于自己大学的经历，当时抱着一腔热血去学计算机编程，可是当把c/c++语言，数据结构，操作系统，计算机组成原理等课程都学完后，却发现自己似乎什么也不会，只会printf打印一些字符串。那段时间真的好苦恼，特别想做软件，却不知从何开始，也不知道该如何去使力，蹉跎了好久，浪费了大量的时间。 造成这种现象的主要原因，一是自己缺少那种天赋，二是教学过于侧重基础和理论，每门课程只涉及到一个局部，没有一门课程把这些串起来。我不了解语言的基础库，除了printf后，其它API都不会用；也不了解具体的操作系统平台的API；虽然学了TCP/IP，socket的具体使用却又不清楚； 至于像fat,ext等磁盘文件系统的格式，那就更遥远了；我甚至还不清楚计算机语言和编译工具的关系；更要命的是，我还不知道自己不知道这些。说白了就是理论同应用脱节，虽然大学也安排了课程设计，实验和实习，但都只是走了过场，也没有人来指点一下，该看些什么书籍。大学读完，就知道拖拉几个控件做一个窗口，连接一下数据库。 windows + VC屏蔽了太多的技术细节，可惜大学期间接触的偏偏就是它，对用户这个是好事越傻瓜越好，可是对计算机的学生就要了命了。自从我转投到linux开源世界后，终于才发现了什么是自由，什么是编程。当阅读linux源码碰到不理解的地方，可以直接修改源码加上打印，分析kernel流程。对比着minix的源码来学习操作系统结构原理，那些概念就变成实实在在的数据结构和算法，动手写一个minix的驱动，微内核和宏内核区别就一目了然了。强烈建议，想学习编程的同学都去拥抱开源世界，然后，再回到自己感兴趣的或工作相关的领域。 计算机语言说白了就是工具，关键还是你要做什么，这样就涉及到了应用，以及专业背景知识。如想做驱动编程，离不开对操作系统驱动架构的了解；想做一个磁盘分区合并，那需要了解文件系统的格式；做个播放器吧，那对视频文件格式，编码格式，编解码API的了解必不可少。 随着你对软件系统了解的深入，会发现其实一切都是协议。 http 是一套web 通讯的协议；计算机语言是开发工具提供的协议； 操作系统是内核空间与应用空间的协议...， 这些协议被各种规范约束－－并形成了各种技术。 所以，每种技术的背后都一套协议，规则和思想。了解这些才能算真正了解了相关技术。 在这篇文章里面，我以GNU/Linux作为平台，从应用的角度出发来把相关的课程来串一串提供一个“物理视图”，让初学者有个全局的认识，能够有一个方向和切入角度，至少知道该找些什么资料来看。 操作系统接口它是内核对应用空间提供的一套协议，主要包括： ABI可执行文件的结构。系统调用(system call)。sysfs 文件系统接口(linux kernel)。ELF是编译， 链接生成的，执行的时候，由ld 解析，加载在到内存，最后控制权交给程序入口代码，程序开始执行。因此，它提供了2类视图：链接视图和执行视图。 从链接视图上看，ELF由众多的 Section组成，编译器先把源码编译成.o文件，主要是提取函数，全局变量等生成符号表，把它们填充到相应的 Section里面去。 在这个阶段，所有的符号都是没法定位到地址的。 Link的时候，对.o文件进行合并，对各个文件内的符号进行重定位，安排它们的地址，如下图所示， link完成后，g_u8 和 g_flag2都有地址了。 对于动态链接的函数，在link阶段没法安排地址，需要放到 dynsym Section里面去，在 ld的时候，来进行定位 －－ 这就是所谓的 "函数重定位"。linux系统提供了可执行程序readelf来解析 ELF文件格式，我们可以使用它来了解一下ELF文件的一些通用的Section。 bss 是没有指定初始化值的数据， 有些编译器会默认全部初始化为0。data 全局变量初始化。text 代码。init 程序初始化运行的代码。fini 程序结束运行的代码。symtab 符号表， 它是源码编译生成的产物，可以为代码运行，调试提供信息。 属于辅助性质，不参与 load 和运行， 可以用 strip来删除掉。'offset Align' 是各个Section在ELF文件内的偏移地址，我们以二进制的方式打开ELF文件，根据偏移地址，就可以查看相应Section的二进制内容。 从下图中可以看到 .interp的内容是 "/lib64/ld-linux-x86-64.so.2"， 上面这些就是编译，链接生成ELF文件的过程：编译器以源文件作为输入，先提取各个文件的全局变量和函数，生成符号表，再把它们链接到一起，链接的时候对各个符号进行定位，分配地址。对于动态链接库的函数，则推迟到'加载'程序到内存的时候进行定位。编译链接后，代码和数据分散到了相应的section里面，程序加载的时候，需要把Section 合并成Secgment，然后，以Secgement为单位加载到内存页面里面去，我们来看一下Segment的结构。 ELF有9种Segment，其中比较核心的是 －－ ...

1. Linux常见的文件系统EXT（Extended File System） EXT2：Linux的第一个设计为一个商业级文件系统，沿用 BSD 的 Berkeley 文件系统的设计原理。提供了GB级别的最大文件和TB级别的文件系统。但是如果在将数据写入到磁盘的时候，系统发生崩溃或断电，则容易发生灾难性的数据损坏。EXT3：使用 32 位内部寻址，引入日志事务解决了EXT2数据损坏问题。三个级别的日志记录方式日记(journal)、 顺序(ordered)和 回写(writeback)。EXT4：使用 48 位的内部寻址，可以存储最大16TB的单一文件，支持最大1EB的分区容量。EXT -> EXT2 -> EXT3 -> EXT4XFS （Extents File System） 它是一个 64 位的日志文件系统，自 2001 年以来内置于 Linux 内核中，为大型文件系统和高度并发性提供了高性能（即大量的进程都会立即写入文件系统）。从 RHEL 7 开始，XFS 成为 Red Hat Enterprise Linux 的默认文件系统。ZFS（Zettabyte File System） Sun Microsystems 开发，以 zettabyte 命名 —— 相当于 1 万亿 GB —— 因为它理论上可以解决大型存储系统。Btrfs（B-Tree Filesystem） Chris Mason 于 2007 年在 Oracle 任职期间发布。Btrfs 旨在跟 ZFS 有大部分相同的目标，提供多种设备管理、每块校验、异步复制、直列压缩等等。SUSE Enterprise Linux 在 2015 年采用它作为默认文件系统，而 Red Hat 于 2017 年宣布它从 RHEL 7.4 开始不再支持 Btrfs。2. Linux系统的层次 ======================================================= | Application | User space ======================================================= | SCI (System Call Interface) | K |-----------------------------------------------------| e | VFS (Virtual File System) | r |-----------------------------------------------------| n | Ext3 | Ext4 | XFS | ZFS | Btrfs | ... | e |-----------------------------------------------------| l | General Block Device Layer | |-----------------------------------------------------| Kernel space | Device Driver | ======================================================= | Physical Disk | Hardware ======================================================= 清单2-1 ...