1.文件系统与分区

①磁盘分区完毕后还需要进行格式化（ format） ， 之后操作系统才能够使用这个文件系统。 为什么需要进行“格式化”呢？ 这是因为每种操作系统所设置的文件属性/权限并不相同， 为了存放这些文件所需的数据， 因此就需要将分区进行格式化， 以成为操作系统能够利用的“文件系统格式（ filesystem） ”。
②每种操作系统能够使用的文件系统并不相同。 举例来说， windows 98以前的微软操作系统主要利用的文件系统是 FAT （ 或 FAT16） ， windows 2000 以后的版本有所谓的 NTFS 文件系统， 至于 Linux 的正统文件系统则为 Ext2 （ Linux second extendedfile system, ext2fs） 这一个。 此外， 在默认的情况下， windows 操作系统是不会认识 Linux的 Ext2 的。
③传统的磁盘与文件系统之应用中， 一个分区就是只能够被格式化成为一个文件系统， 所以我们可以说一个 filesystem 就是一个 partition。 但是由于新技术的利用， 例如我们常听到的LVM与软件磁盘阵列（ software raid） ， 这些技术可以将一个分区格式化为多个文件系统（ 例如LVM） ， 也能够将多个分区合成一个文件系统（ LVM, RAID） ！ 所以说， 目前我们在格式化时已经不再说成针对 partition 来格式化了， 通常我们可以称呼一个可被挂载的数据为一个文件系统而不是一个分区喔！。

2. inode、block和superblock

superblock： 记录此 filesystem 的整体信息， 包括inode/block的总量、 使用量、 剩余量，以及文件系统的格式与相关信息等；
inode： 记录文件的属性， 一个文件占用一个inode， 同时记录此文件的数据所在的 block号码；
block： 实际记录文件的内容， 若文件太大时， 会占用多个 block 。

Tips:常见的文件系统

文件系统	特点
FAT32 (File Allocation Table 32)	主要用于U盘、SD卡等小容量存储设备，兼容性好；单个文件最大只能为4GB，不适合存储大文件；常用于需要跨操作系统使用的场景，比如Windows、Linux和macOS。
exFAT (Extended File Allocation Table)	由微软开发，用于替代FAT32，支持更大的文件（不受4GB限制）；适用于大容量U盘和SD卡，兼容Windows、macOS和部分Linux系统；不如FAT32广泛兼容，但更适合存储大文件。
NTFS (New Technology File System)	Windows的默认文件系统，支持较大的文件和分区；具备文件权限、加密、压缩等高级功能；在Linux和macOS上读写支持有限，通常需要安装第三方工具。
HFS+ (Hierarchical File System Plus)	主要用于macOS系统，提供良好的性能和数据保护功能；现在逐渐被APFS取代，但在旧版本macOS和部分存储设备上仍然使用。
APFS (Apple File System)	苹果在macOS High Sierra及以上版本使用的文件系统，优化了SSD的读写性能；提供快照、加密和空间共享功能，适合现代存储需求；仅在macOS和iOS上有完全支持。
EXT (Extended File System)	ext2：Linux最早的文件系统之一，不支持日志功能，数据恢复困难；ext3：在ext2的基础上增加了日志功能，数据可靠性提高；ext4：目前大部分Linux发行版的默认文件系统，支持更大的分区和文件，性能和稳定性更好。
Btrfs (B-tree File System)	主要用于Linux系统，支持快照、压缩、多设备存储和子卷管理；提供了更高的容错和恢复能力，适合大型数据存储和服务器。
XFS	高性能的64位日志文件系统，常用于Linux中的大型存储和数据库应用；支持高并发和大文件，适合需要高速读写的场景。
ZFS (Zettabyte File System)	支持快照、数据完整性检查、自修复等功能，数据保护和恢复能力强；适用于数据中心和高可靠性需求的存储环境；最初由Sun Microsystems开发，广泛应用于FreeBSD和Linux。

linux支持的文件系统：

分别在Ubuntu22和Centos7中查看文件系统类型：

fle@fle-virtual-machine:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.4 LTS
Release:	22.04
Codename:	jammy
fle@fle-virtual-machine:~$ df -T
文件系统       类型      1K的块     已用     可用 已用% 挂载点
tmpfs          tmpfs     808408     2112   806296    1% /run
/dev/sda3      ext4    50770432 25839172 22319856   54% /
tmpfs          tmpfs    4042028        0  4042028    0% /dev/shm
tmpfs          tmpfs       5120        4     5116    1% /run/lock
tmpfs          tmpfs    4042028        0  4042028    0% /run/qemu
/dev/sda2      vfat      524252     6220   518032    2% /boot/efi
tmpfs          tmpfs     808404      120   808284    1% /run/user/1000
/dev/sr0       iso9660  4899762  4899762        0  100% /media/fle/Ubuntu 22.04.4 LTS amd64

[fle@CentOS7 ~]$ lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	CentOS
Description:	CentOS Linux release 7.9.2009 (Core)
Release:	7.9.2009
Codename:	Core
[fle@CentOS7 ~]$ df -T
文件系统                类型        1K-块    已用    可用 已用% 挂载点
devtmpfs                devtmpfs   480824       0  480824    0% /dev
tmpfs                   tmpfs      497848       0  497848    0% /dev/shm
tmpfs                   tmpfs      497848    8752  489096    2% /run
tmpfs                   tmpfs      497848       0  497848    0% /sys/fs/cgroup
/dev/mapper/centos-root xfs      10475520 7756292 2719228   75% /
/dev/sda2               xfs       1038336  177032  861304   18% /boot
/dev/mapper/centos-home xfs       5232640  128248 5104392    3% /home
tmpfs                   tmpfs       99572      36   99536    1% /run/user/1000
/dev/sr0                iso9660   9961428 9961428       0  100% /run/media/fle/CentOS 7 x86_64

从上面可以看到，Ubuntu的文件系统为ext4，而Centos7的文件系统为xfs.
ext文件系统有inode，而FAT系统是没有的，下图显示了ext和FAT在读取文件时的不同：

从上图可以看到，ext文件系统根据inode中记录的block号码进行索引，而FAT因为没有inode只能进行类似链表的操作。这也导致了ext系统读取文件可以比FAT快得多。

3.EXT2的文件系统

Ext2 文件系统在格式化的时候基本上是区分为多个区块群组 （ block group） 的， 每个区块群组都有独立的inode/block/superblock 系统

文件系统最前面有一个开机扇区（ boot sector） ， 这个开机扇区可以安装开机管理程序， 这是个非常重要的设计， 因为如此一来我们就能够将不同的开机管理程序安装到个别的文件系统最前端， 而不用覆盖整颗磁盘唯一的 MBR， 这样也才能够制作出多重开机的环境啊！
下面介绍一个block group的6个组成部分：

3.1 data block

首先需要说明的是，一旦格式化之后，data block的大小和数量就已经固定了，除非重新格式化。

对于data block，存在以下特点：
①原则上， block 的大小与数量在格式化完就不能够再改变了（ 除非重新格式化） ；
②每个 block 内最多只能够放置一个文件的数据；
③承上， 如果文件大于 block 的大小， 则一个文件会占用多个 block 数量；
④承上， 若文件小于 block ， 则该 block 的剩余容量就不能够再被使用了（ 磁盘空间会浪费） 。

可以注意到，因为现在硬盘容量都非常大了，所以一般都直接选用最大的4KB.
可以使用ls -l来查看文件大小，除以4KB就是占用的data block个数:

fle@fle-virtual-machine:/$ ls -l
总计 2097232
lrwxrwxrwx   1 root root          7  2月 29  2024 bin -> usr/bin
drwxr-xr-x   4 root root       4096 11月  6 16:22 boot
drwxrwxr-x   2 root root       4096  2月 29  2024 cdrom
drwxr-xr-x  19 root root       4340 11月  6 15:11 dev
drwxr-xr-x 136 root root      12288 11月  6 16:22 etc
drwxr-xr-x   3 root root       4096  2月 29  2024 home
lrwxrwxrwx   1 root root          7  2月 29  2024 lib -> usr/lib
lrwxrwxrwx   1 root root          9  2月 29  2024 lib32 -> usr/lib32
lrwxrwxrwx   1 root root          9  2月 29  2024 lib64 -> usr/lib64
lrwxrwxrwx   1 root root         10  2月 29  2024 libx32 -> usr/libx32
drwx------   2 root root      16384  2月 29  2024 lost+found
drwxr-xr-x   3 root root       4096  3月  1  2024 media
...

3.2 inode Table

3.2.1 inode记录的内容

inode记录的内容如下：
①该文件的存取模式（ read/write/excute） ；
②该文件的拥有者与群组（ owner/group） ；
③该文件的容量；
④该文件创建或状态改变的时间（ ctime） ；
⑤最近一次的读取时间（ atime） ；
⑥最近修改的时间（ mtime） ；
⑦定义文件特性的旗标（ flag） ， 如 SetUID…；
⑧该文件真正内容的指向 （ pointer） ；
Tips:inode的大小和数量也是在格式化的时候就已经固定了。

3.2.2 inode特点

对于inode,存在以下特点：
①每个 inode 大小均固定为 128 Bytes （ 新的 ext4 与 xfs 可设置到 256 Bytes） ；
②每个文件都仅会占用一个 inode 而已；
③承上， 因此文件系统能够创建的文件数量与 inode 的数量有关；
④系统读取文件时需要先找到 inode， 并分析 inode 所记录的权限与使用者是否符合， 若符合才能够开始实际读取 block 的内容。
一个data block大小为4KB,如果一个文件400M，那么需要400*1024/4=102400个data block，inode需要记录每个data block的号码，显然128B的大小是不够的，所以有了下图所示这样的直接，间接，双间接，三间接的方式，其实就是拿一些data block也来记录data block的号码。

可以用ls -li来显示每个文件的inode:

fle@fle-virtual-machine:~$ ls -li
总计 44
1484035 drwxr-xr-x 2 fle fle 4096  3月  1  2024 公共的
1484034 drwxr-xr-x 2 fle fle 4096  3月  1  2024 模板
1484039 drwxr-xr-x 2 fle fle 4096  3月  1  2024 视频
1484038 drwxr-xr-x 2 fle fle 4096  3月  1  2024 图片
1484036 drwxr-xr-x 2 fle fle 4096  3月  1  2024 文档
1484033 drwxr-xr-x 2 fle fle 4096 11月  3 13:18 下载
1484037 drwxr-xr-x 2 fle fle 4096  3月  1  2024 音乐
1484032 drwxr-xr-x 8 fle fle 4096 11月  3 13:19 桌面
1605322 drwxrwxr-x 2 fle fle 4096  3月  5  2024 calTool
1574661 drwxrwxr-x 3 fle fle 4096  4月  7  2024 eqmu_8.2.0
1483948 drwx------ 6 fle fle 4096  3月  7  2024 snap

上面中第一个参数就是文件的inode号码

3.3 Superblock

Superblock对文件系统尤为重要，因为其记录了文件系统的整体信息：
①block 与 inode 的总量；
②未使用与已使用的 inode / block 数量；
③block 与 inode 的大小 （ block 为 1, 2, 4K， inode 为 128Bytes 或 256Bytes） ；
④filesystem 的挂载时间、 最近一次写入数据的时间、 最近一次检验磁盘 （ fsck） 的时间等文件系统的相关信息；
⑤一个 valid bit 数值， 若此文件系统已被挂载， 则 valid bit 为 0 ， 若未被挂载， 则 valid bit为 1 。
Tips:前面我们提到，一个文件系统有多个block group,但是一个文件系统只会有一种Superblock信息，所以没有block group可能含有或不含有Superblock，就算有，它们记录的信息也是一样的。

3.4 Filesystem Description(文件系统描述说明)

Filesystem Description对于所在的block group是重要的，因为Filesystem Description描述了block group 的开始与结束的 block 号码， 以及说明每个区段（ superblock, bitmap, inodemap, data block） 分别介于哪一个 block 号码之间。

3.5 block bitmap （ 区块对照表）

如果你想要新增文件时总会用到 block 吧！ 那你要使用哪个 block 来记录呢？ 当然是选择“空的 block ”来记录新文件的数据啰。 那你怎么知道哪个 block 是空的？ 这就得要通过 block bitmap 的辅助了。 从 block bitmap 当中可以知道哪些 block 是空的， 因此我们的系统就能够很快速的找到可使用的空间来处置文件啰。同样的， 如果你删除某些文件时， 那么那些文件原本占用的 block 号码就得要释放出来， 此时在 block bitmap 当中相对应到该 block 号码的标志就得要修改成为“未使用中”啰！ 这就是bitmap 的功能。

3.6 inode bitmap （ inode 对照表）

这个其实与 block bitmap 是类似的功能， 只是 block bitmap 记录的是使用与未使用的 block号码， 至于 inode bitmap 则是记录使用与未使用的 inode 号码啰！

4.查看文件系统信息的指令——dumpe2fs

查看EXT文件系统的Superblock——dumpe2fs

[root@study ~]# dumpe2fs [-bh] 设备文件名
選項與參數：
-b ：列出保留為壞軌的部分(一般用不到吧！？)
-h ：僅列出 superblock 的資料，不會列出其他的區段內容！範例：鳥哥的一塊 1GB ext4 檔案系統內容
[root@study ~]# blkid   <==這個指令可以叫出目前系統有被格式化的裝置
/dev/vda1: LABEL="myboot" UUID="ce4dbf1b-2b3d-4973-8234-73768e8fd659" TYPE="xfs"
/dev/vda2: LABEL="myroot" UUID="21ad8b9a-aaad-443c-b732-4e2522e95e23" TYPE="xfs"
/dev/vda3: UUID="12y99K-bv2A-y7RY-jhEW-rIWf-PcH5-SaiApN" TYPE="LVM2_member"
/dev/vda5: UUID="e20d65d9-20d4-472f-9f91-cdcfb30219d6" TYPE="ext4"  <==看到 ext4 了！[root@study ~]# dumpe2fs /dev/vda5
dumpe2fs 1.42.9 (28-Dec-2013)
Filesystem volume name:   <none>           # 檔案系統的名稱(不一定會有)
Last mounted on:          <not available>  # 上一次掛載的目錄位置
Filesystem UUID:          e20d65d9-20d4-472f-9f91-cdcfb30219d6
Filesystem magic number:  0xEF53           # 上方的 UUID 為 Linux 對裝置的定義碼
Filesystem revision #:    1 (dynamic)      # 下方的 features 為檔案系統的特徵資料
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl   # 預設在掛載時會主動加上的掛載參數
Filesystem state:         clean            # 這塊檔案系統的狀態為何，clean 是沒問題
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              65536            # inode 的總數
Block count:              262144           # block 的總數
Reserved block count:     13107            # 保留的 block 總數
Free blocks:              249189           # 還有多少的 block 可用數量
Free inodes:              65525            # 還有多少的 inode 可用數量
First block:              0
Block size:               4096             # 單個 block 的容量大小
Fragment size:            4096
Group descriptor size:    64
....(中間省略)....
Inode size:               256              # inode 的容量大小！已經是 256 了喔！
....(中間省略)....
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      3c2568b4-1a7e-44cf-95a2-c8867fb19fbc
Journal backup:           inode blocks
Journal features:         (none)
Journal size:             32M              # Journal 日誌式資料的可供紀錄總容量
Journal length:           8192
Journal sequence:         0x00000001
Journal start:            0Group 0: (Blocks 0-32767)                  # 第一塊 block group 位置Checksum 0x13be, unused inodes 8181Primary superblock at 0, Group descriptors at 1-1   # 主要 superblock 的所在喔！Reserved GDT blocks at 2-128Block bitmap at 129 (+129), Inode bitmap at 145 (+145)Inode table at 161-672 (+161)                       # inode table 的所在喔！28521 free blocks, 8181 free inodes, 2 directories, 8181 unused inodesFree blocks: 142-144, 153-160, 4258-32767           # 底下兩行說明剩餘的容量有多少Free inodes: 12-8192
Group 1: (Blocks 32768-65535) [INODE_UNINIT]          # 後續為更多其他的 block group 喔！
....(底下省略)....
# 由於資料量非常的龐大，因此鳥哥將一些資訊省略輸出了！上表與你的螢幕會有點差異。
# 前半部在秀出 supberblock 的內容，包括標頭名稱(Label)以及inode/block的相關資訊
# 後面則是每個 block group 的個別資訊了！您可以看到各區段資料所在的號碼！
# 也就是說，基本上所有的資料還是與 block 的號碼有關就是了！很重要！

5.目录文件的inode和block、文件读取、新增过程

5.1 目录文件的inode和block

当我们在 Linux 下的文件系统创建一个目录时， 文件系统会分配一个 inode 与至少一块 block给该目录。 其中， inode 记录该目录的相关权限与属性， 并可记录分配到的那块 block 号码；而 block 则是记录在这个目录下的文件名与该文件名占用的 inode 号码数据。也就是说目录所占用的 blockn内容在记录如下的信息：

也就是说，目录文件的 inode 本身并不记录文件名， 文件名的记录是在目录的 block 当中。其实这也就是为什么在目录权限中，w的含义是“新增/删除/更名文件了”，因为w指的是data block可写。

5.2 文件读取

下面通过一个例子来直观理解文件搜索过程中是如何通过inode和block来操作的（读取passwd文件）：

5.3 文件新增过程

用于防止新增文件错误的日志系统：
在一般正常的情况下， 上述的新增动作当然可以顺利的完成。 但是如果有个万一怎么办？ 例如你的文件在写入文件系统时， 因为不知名原因导致系统中断（ 例如突然的停电啊、 系统核心发生错误啊～等等的怪事发生时） ， 所以写入的数据仅有 inode table 及 data block 而已，最后一个同步更新中介数据的步骤并没有做完， 此时就会发生 metadata 的内容与实际数据存放区产生不一致 （ Inconsistent） 的情况了。
如果要针对 metadata 区域与实际数据存放区来进行比对，那太费时了，这个时候就需要用到日志系统了：
在我们的 filesystem 当中规划出一个区块， 该区块专门在记录写入或修订文件时的步骤， 那不就可以简化一致性检查的步骤了？ 也就是说：
1、预备： 当系统要写入一个文件时， 会先在日志记录区块中纪录某个文件准备要写入的信
息；
2、实际写入： 开始写入文件的权限与数据； 开始更新 metadata 的数据；
3、结束： 完成数据与 metadata 的更新后， 在日志记录区块当中完成该文件的纪录。
在这样的程序当中， 万一数据的纪录过程当中发生了问题， 那么我们的系统只要去检查日志记录区块， 就可以知道哪个文件发生了问题， 针对该问题来做一致性的检查即可， 而不必针对整块 filesystem 去检查， 这样就可以达到快速修复 filesystem 的能力了！ 这就是日志式文件最基础的功能啰～
Tips:EXT2没有日志功能，EXT3/4才有。

6.clean与dirty

所有的数据都得要载入到内存后 CPU 才能够对该数据进行处理。 想一想， 如果你常常编辑一个好大的文件， 在编辑的过程中又频繁的要系统来写入到磁盘中， 由于磁盘写入的速度要比内存慢很多， 因此你会常常耗在等待磁盘的写入/读取上。 真没效率！
为了解决这个效率的问题， 因此我们的 Linux 使用的方式是通过一个称为非同步处理（ asynchronously） 的方式。 所谓的非同步处理是这样的：当系统载入一个文件到内存后， 如果该文件没有被更动过， 则在内存区段的文件数据会被设
置为干净（ clean） 的。 但如果内存中的文件数据被更改过了（ 例如你用 nano 去编辑过这个文件） ， 此时该内存中的据会被设置为脏的 （ Dirty） 。 此时所有的动作都还在内存中执行， 并没有写入到磁盘中！ 系统会不定时的将内存中设置为“Dirty”的数据写回磁盘， 以保持磁盘与内存数据的一致性。

7.挂载点

7.1 挂载的定义

挂载（Mount）是在操作系统中将一个存储设备（例如硬盘分区、光盘、U盘、网络文件系统等）连接到目录树的过程，使得用户可以通过文件系统路径访问该设备上的内容。挂载之后，设备上的文件和目录将被映射到操作系统的文件系统结构中，从而变得可访问。
Tips:挂载点必须是目录。

7.2 挂载的意义

在安装CentOS7的时候，对储存设备的分区是这样的：

也就是说/boot、/、/home均设置为了挂载点。

[root@CentOS7 ~]# ls -lid / /boot /home
64 dr-xr-xr-x. 17 root root  244 6月  21 16:56 /
64 dr-xr-xr-x.  6 root root 4096 5月  18 21:03 /boot
64 drwxr-xr-x.  7 root root   73 9月  29 16:55 /home

可以看到，64这个位置表示的是目录的inode号码，/boot、/、/home作为xfs系统最顶层的目录，其inode是一样的。17、6、7位置表示的是有多少个inode链接到该目录（对于文件来说，该位置为1，因为一个文件对应一个inode,对于目录来说，则是该目录的block记录了多少个文件，即多少个inode）。

8.VFS（ Virtual Filesystem Switch）

了解了我们使用的文件系统之后， 再来则是要提到， 那么 Linux 的核心又是如何管理这些认识的文件系统呢？ 其实， 整个 Linux 的系统都是通过一个名为 Virtual Filesystem Switch 的核心功能去读取 filesystem 的。 也就是说， 整个 Linux 认识的 filesystem 其实都是 VFS 在进行管理， 我们使用者并不需要知道每个 partition 上头的 filesystem 是什么～ VFS 会主动的帮我们做好读取的动作呢～

9.XFS文件系统

9.1 XFS的优势

CentOS 7 开始， 默认的文件系统已经由原本的 EXT4 变成了 XFS 文件系统了！ 为啥CentOS 要舍弃对 Linux 支持度最完整的 EXT 家族而改用 XFS ：
①EXT 家族当前较伤脑筋的地方： 支持度最广， 但格式化超慢
Ext 文件系统家族对于文件格式化的处理方面， 采用的是预先规划出所有的 inode/block/metadata 等数据， 未来系统可以直接取用， 不需要再进行动态配置的作法。
②XFS 文件系统的配置
基本上 xfs 就是一个日志式文件系统， 而 CentOS 7.x 拿它当默认的文件系统， 自然就是因为最早之前， 这个 xfs 就是被开发来用于大容量磁盘以及高性能文件系统之用， 因此， 相当适合现在的系统环境。 此外， 几乎所有 Ext4 文件系统有的功能， xfs 都可以具备。

9.2 XFS文件系统框架

①数据区（data section）
数据区就跟我们之前谈到的 ext 家族一样， 包括 inode/data block/superblock 等数据， 都放置在这个区块。不同的是，inode与 block 都是系统需要用到时， 这才动态配置产生， 所以格式化动作超级快
②文件系统活动登录区 （log section）
在登录区这个区域主要被用来纪录文件系统的变化， 其实有点像是日志区啦！ 文件的变化会在这里纪录下来， 直到该变化完整的写入到数据区后， 该笔纪录才会被终结。
③实时运行区 （ realtime section）
当有文件要被创建时， xfs 会在这个区段里面找一个到数个的 extent 区块， 将文件放置在这个区块内， 等到分配完毕后， 再写入到 data section 的 inode 与 block 去！ 这个 extent 区块的大小得要在格式化的时候就先指定。
Tips:XFS 文件系统的描述数据观察指令——xfs_info。