Linux基础知识——文件系统 素颜马尾好姑娘i 2022-12-02 10:58 211阅读 0赞 # 一、文件系统 # ## 1. 分区与文件系统 ## 我们对磁盘进行分区完毕后,还需要进行格式化(format),对分区进行格式化是为了在分区上建立文件系统,即`把分区格式化成为一个文件系统`。 一个分区通常只能格式化为一个文件系统,但是磁盘阵列等技术可以将一个分区格式化为多个文件系统,也可以把多个分区格式化为一个文件系统。 而且,每种操作系统能够使用的文件系统并不相同,举例来说: * Windows系统的文件系统:FAT / FAT16(windows 98 以前),NTFS (windows 2000 以后) * Linux系统的文件系统: Ext2 (Linux second extended file system, ext2fs)、xfs(CentOS 7) 此外,在默认的情况下,Windows 操作系统是不会认识 Linux 的 Ext2 的。 ## 2. 文件系统的组成 ## 最主要的几个组成部分如下: * inode:一个文件占用一个 inode,记录文件的属性,同时记录此文件的内容所在的 block 编号; * block:记录文件的内容,文件太大时,会占用多个 block。 每个 inode 与 block 都有编号。 除此之外还包括: * superblock:记录文件系统的整体信息,包括 inode 和 block 的总量、使用量、剩余量,以及文件系统的格式与相关信息等; * block bitmap:记录 block 是否被使用的位图。 ## 3. 文件读取 ## 对于 Ext2 文件系统,当要读取一个文件的内容时,先在 inode 中查找文件内容所在的所有 block,然后把所有 block 的内容一次性读出来。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center] 而对于 FAT 文件系统,它没有 inode,每个 block 中存储着下一个 block 的编号,所以需要一个一个地将 block 读出来。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 1] ## 4. 磁盘碎片 ## 指一个文件内容所在的 block 过于分散,导致磁盘磁头移动距离过大,从而降低磁盘读写性能。 这个时候可以通过将同一个文件所属的 blocks 汇整在一起,这样数据的读取会比较容易,即**磁盘重组**。 ## 5. Linux 的 EXT2 文件系统(inode) ## 因为 inode 与 block 的数量太庞大,不容易管理,所以Ext2 文件系统在格式化的时候基本上是区分为多个区块群组 (block group) 的,每个区块群组都有独立的 inode / block / superblock 系统,如下图所示。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 2] ### block table ### data table 包含多个 block,是用来放置文件内容数据的地方。在 Ext2 文件系统中所支持的 block 大小有 1K, 2K 及 4K 三种而已。在格式化时, block 的大小就固定了,且每个 block 都有编号,以方便 inode 的记录啦。不同大小的 block (1K, 2K 及 4K) 限制了单个文件和文件系统的最大大小。 <table> <thead> <tr> <th align="center">大小</th> <th align="center">1KB</th> <th align="center">2KB</th> <th align="center">4KB</th> </tr> </thead> <tbody> <tr> <td align="center">最大单一文件</td> <td align="center">16GB</td> <td align="center">256GB</td> <td align="center">2TB</td> </tr> <tr> <td align="center">最大文件系统</td> <td align="center">2TB</td> <td align="center">8TB</td> <td align="center">16TB</td> </tr> </tbody> </table> 如果 block 较大时,一个 block 只能被一个文件所使用,未使用的部分直接浪费了。因此如果需要存储大量的小文件,那么最好选用比较小的 block。 如果 block 较小的话,那么大型文件将会占用数量更多的 block ,而 inode 也要记录更多的 block 号码,此时将可能导致文件系统不良的读写性能。 Ext2 文件系统的 block 的基本限制: * 原则上,block 的大小与数量在格式化完就不能够再改变了(除非重新格式化); * 每个 block 内最多只能够放置一个文件的数据; * 承上,如果文件大于 block 的大小,则一个文件会占用多个 block 数量; * 承上,若文件小于 block ,则该 block 的剩余容量就不能够再被使用了(磁盘空间会浪费)。 ### inode table (inode 表格) ### inode table 包含多个 inode ,inode 中记录着文件的属性以及该文件实际数据是放置在哪几号 block 内。因此,inode 记录的文件数据至少有下面这些: * 该文件的存取模式(read/write/excute); * 该文件的拥有者与群组(owner/group); * 该文件的容量; * 该文件创建或状态改变的时间(ctime); * 最近一次的读取时间(atime); * 最近修改的时间(mtime); * 定义文件特性的旗标(flag),如 SetUID…; * 该文件真正内容的指向 (pointer); inode 的数量与大小也是在格式化时就已经固定了,inode的基本限制如下: * 每个 inode 大小均固定为 128 Bytes (新的 ext4 与 xfs 可设置到 256 Bytes); * 每个文件都仅会占用一个inode 而已; * 承上,因此文件系统能够创建的文件数量与 inode 的数量有关; * 系统读取文件时需要先找到 inode,并分析 inode 所记录的权限与使用者是否符合,若符 合才能够开始实际读取 block 的内容。 inode 结构示意图如下所示,inode 中记录了文件内容所在的 block 编号,但是每个 block 非常小,一个大文件随便都需要几十万的 block。而一个 inode 大小有限,无法直接引用这么多 block 编号。因此引入了间接、双间接、三间接引用。至于所谓的间接就是再拿一个 block 来当作记录 block 号码的记录区,如果文件太大时, 就会使用间接的 block 来记录号码。双间接、三间接以此类推可知。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 3] 这样子 inode 能够指定多少个 block 呢?以较小的 1K block为例,可以指定的情 况如下: * 12 个直接指向: 12\*1K=12K 由于是直接指向,所以总共可记录 12 笔记录,因此总额大 小为如上所示; * 间接:256\*1K=256K 每笔 block 号码的记录会花去 4Bytes,因此 1K 的大小能够记录 256笔记录,因此一个间接可以记录的文件大小如上; * 双间接: 2562561K=2562K 第一层 block 会指定 256个第二层,每个第二层可以指定 256 个号码,因此总额大小如上; * 三间接: 256256256\*1K=2563K 第一层 block 会指定 256 个第二层,每个第二层可以指 定 256 个第三层,每个第三层可以指定 256 个号码,因此总额大小如上; * 总额:将直接、间接、双间接、三间接加总,得到 12 + 256 + 256256 + 256256\*256 (K) = 16GB 因此,我们知道当文件系统将 block 格式化为 1K 大小时,能够容纳的最大文件为 16GB。 ### Superblock (超级区块) ### Superblock 是记录整个 filesystem 相关信息的地方, 没有 Superblock ,就没有这个 filesystem了。它记录的信息主要有: * block 与 inode 的总量; * 未使用与已使用的 inode / block 数量; * block 与 inode 的大小(block 为 1, 2, 4K,inode 为 128Bytes 或 256Bytes); * filesystem的挂载时间、最近一次写入数据的时间、最近一次检验磁盘 (fsck) 的时间等文件系统的相关信息; * 一个 valid bit 数值,若此文件系统已被挂载,则 valid bit 为 0 ,若未被挂载,则 valid bit 为 1 。 此外,每个 block group 都可能含有 superblock 喔!但是我们也说一个文件系统应该仅有一个superblock 而已,那是怎么回事啊? 事实上除了第一个 block group 内会含有 superblock之外,后续的 block group 不一定含有 superblock , 而若含有 superblock 则该 superblock主要是做为第一个 block group 内 superblock 的备份咯,这样可以进行 superblock 的救援呢! ### Filesystem Description (文件系统描述说明) ### 这个区段可以描述每个 block group 的开始与结束的 block 号码,以及说明每个区段(superblock, bitmap, inodemap, data block) 分别介于哪一个 block 号码之间。 ### block bitmap (区块对照表) ### block bitmap 中记录着每个 block 的状态(已被使用/未被使用) ### inode bitmap (inode 对照表) ### inode bitmap 中记录着每个 inode 的状态(已被使用/未被使用) ## 目录 ## 建立一个目录时,会分配一个 inode 与至少一个 block。block 记录的内容是目录下所有文件的 inode 编号及对应的文件名,如下图所示。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 4] 可以看到文件的 inode 本身不记录文件名,文件名记录在目录中,因此新增文件、删除文件、更改文件名这些操作与目录的写权限有关。 ## 目录树读取 ## 当我们要读取某个文件时,就务必会经过目录的 inode 与 block ,然后才能够找到那个待读取文件的 inode 号码, 最终才会读到正确的文件的 block 内的数据。 由于目录树是由根目录开始读起,因此系统通过挂载的信息可以找到挂载点的 inode 号码,此时就能够得到根目录的 inode 内容,并依据该 inode 读取根目录的 block 内的文件名数据,再一层一层的往下读到正确的文件名 ## 挂载 ## 挂载利用目录作为文件系统的进入点,也就是说,进入目录之后就可以读取文件系统的数据。 ## 目录配置 ## 为了使不同 Linux 发行版本的目录结构保持一致性,Filesystem Hierarchy Standard (FHS) 规定了 Linux 的目录结构。最基础的三个目录如下: * / (root, 根目录) * /usr (unix software resource):所有系统默认软件都会安装到这个目录; * /var (variable):存放系统或程序运行过程中的数据文件。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 5] ## 创建文件 ## 在 Linux 下的 ext2 创建一个一般文件时, ext2 会分配一个 inode 与相对于该文件大小的 block 数量给该文件。例如:假设我的一个 block 为 4 KBytes ,而我要创建一个 100 KBytes 的文件,那么 linux 将分配一个 inode 与 25 个 block 来储存该文件! 但同时请注意,由于 inode 仅有 12 个直接指向,因此还要多一个 block 来作为区块号码的记录喔!所以该文件实际占用25(24 + 1)个 block ,实际占用的空间为 104 KBytes 。 [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/5638cb64a5c342d2897f678dcddc4c33.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/fcc3277504d040e4b5c25fe84a602970.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/18dda948123c449599e6af11b7edb555.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/b4b1b14979fd4e3f805a2602c87c559c.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/374161ef08254c31b71f4ecbc658c04c.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1YW5tYW9uaW5n_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/1cc63a588c7548cf844d5c7080827e67.png
还没有评论,来说两句吧...