EXT文件系统

Ext类文件系统

全称Linux extended file system, extfs，即Linux扩展文件系统，Ext2就代表第二代文件扩展系统，Ext3/Ext4以此类推，它们都是Ext2的升级版，只不过为了快速恢复文件系统，减少一致性检查的时间，增加了日志功能，所以Ext2被称为索引式文件系统，而Ext3/Ext4被称为日志式文件系统。
Ext2文件系统中将磁盘分区划分为两个主要区域: 元数据区(matadata area)和数据区(data area).

• 元数据区：用于存放文件的属主, 属组, 访问权限, 时间戳以及文件系统数据和元数据分配信息等相关属性信息。
• 数据区：用于存放文件中的真实数据.

每个inode和block都有编号，这三个数据的意义简要的说明如下：

• superblock：记录文件的整体信息，包括inode/block的总量、使用量、剩余量，以及文件系统的格式与相关信息等；

• inode：记录文件属性，一个文件占用一个inode，同时记录此文件的数据所在的block号码；

• block：实际记录文件的内容，若文件太大，会占用多个block。

文件系统主要结构

• 活动扇区（boot sector）
  在整体的规划当中，**文件系统最前面有一个活动扇区（boot sector）， 这个启动扇区可以安装引导装载程序，**这样我们就能够将不同的引导装载程序安装到个别的文件系统最前端，而不用覆盖整块硬盘的唯一MBR。
• block group
  由于现在的物理磁盘的容量大小越来越大, 存储的数据越来越多, 在读取和写入文件有时需要遍历整个磁盘空间, 非常消耗时间, 因此在磁盘分区上创建文件系统时会先将磁盘划分为多个块组(block group), 每个块组中有各自的元数据区和数据区, 并对他们进行独立自治.

superblock

Ext2在格式化的时候基本上是分为多个块组（block group）的，每个文件系统都只应该有一个superblock，还有一个或多个backup superblock。

列出目前系统以及被格式化的文件系统：

# blkid 
/dev/sda1: SEC_TYPE="msdos" UUID="E08D-529D" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="fbbc91b2-66c9-4ec6-b07b-ca4792753fb6" 
/dev/sda2: UUID="2969572a-3dcc-46e8-8ddb-70b350634342" TYPE="xfs" PARTUUID="c4829f36-9360-40fa-970b-5c55b56ae0a0" 
/dev/sda3: UUID="DazaSL-Xwvy-Wt1h-fDPX-pZPI-Uqts-T0HwTY" TYPE="LVM2_member" PARTUUID="317ecf54-70d0-42b5-a8bc-a8ca56f1b474" 
/dev/sdb1: UUID="wc7sGv-Ixp7-Ry1W-4fJX-qkd0-iz4Z-05dZsS" TYPE="LVM2_member" PARTUUID="2b29b334-0ffb-4c32-8efb-42ab260f70cd" 
/dev/sdb2: UUID="PbrlBk-2oQK-G6Vu-Q04z-f82v-hdhh-jWWQcC" TYPE="LVM2_member" PARTUUID="3ce68d1f-464f-40c3-be45-386b6ab93e0d" 
/dev/mapper/centos-root: UUID="6a768255-c3f4-4de4-87e1-db51097aab5d" TYPE="xfs" 
/dev/mapper/centos-swap: UUID="6ce1afd0-864d-4c61-bef1-9fce44941c89" TYPE="swap" 
/dev/mapper/data_home-data_home: UUID="70c2311f-0a22-466e-883f-b392255da039" TYPE="ext4" 
/dev/mapper/centos-home: UUID="adce9bd4-481c-4eaa-b139-3907bf8ba701" TYPE="xfs" 
/dev/mapper/data_samba-data_samba: UUID="5eb9a9eb-5f39-4a90-ad30-a79bd248425c" TYPE="ext4" 

# dumpe2fs -h 只列出supergroup
		   -b 只列出保留为坏轨的部分

# dumpe2fs /dev/mapper/data_home-data_home
Filesystem volume name:   <none>
Last mounted on:          /home
Filesystem UUID:          70c2311f-0a22-466e-883f-b392255da039
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery 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                            =====>>为正常的文件系统
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              261726208							========>>indoe数量
Block count:              1046898688						========>>block数量
Reserved block count:     52344934
Free blocks:              1004507476
Free inodes:              261688260
First block:              0
Block size:               4096							=======>>block大小
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              64
RAID stripe width:        128
Flex block group size:    16
Filesystem created:       Wed Dec 27 10:55:33 2017
Last mount time:          Mon Jan  7 14:21:14 2019
Last write time:          Mon Jan  7 14:21:14 2019
Mount count:              13
Maximum mount count:      -1
Last checked:             Wed Dec 27 10:55:33 2017
Check interval:           0 (<none>)
Lifetime writes:          49 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256								=========>>>每个indoe大小
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      d8b15d88-b87d-4354-9eba-0ccf1ab240a4
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M							=========>> 日志数据的可用容量
Journal length:           32768
Journal sequence:         0x16ad6d3a
Journal start:            14479


Group 0: (Blocks 0-32767) [ITABLE_ZEROED]
  Checksum 0x2bab, unused inodes 8175
  Primary superblock at 0, Group descriptors at 1-500              =========>superblock位置，文件系统描述说明在1-500block中
  Reserved GDT blocks at 501-1524
  Block bitmap at 1525 (+1525), Inode bitmap at 1541 (+1541)
  Inode table at 1557-2068 (+1557)									==========>>indoe table位置
  23013 free blocks, 8176 free inodes, 2 directories, 8175 unused inodes
  Free blocks: 9755-32767
  Free inodes: 17-8192
Group 1: (Blocks 32768-65535) [INODE_UNINIT, ITABLE_ZEROED]
  Checksum 0xadc7, unused inodes 8192
  Backup superblock at 32768, Group descriptors at 32769-33268				=========>backupsuperblock位置
  Reserved GDT blocks at 33269-34292
  Block bitmap at 1526 (bg #0 + 1526), Inode bitmap at 1542 (bg #0 + 1542)
  Inode table at 2069-2580 (bg #0 + 2069)
  2504 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
  Free blocks: 34296-34303, 35248-35263, 35319-35327, 35500-35519, 35542-35583, 35710-35711, 35828-35903, 35944-36031, 36053-36063, 36094-36095, 36187-36223, 36349-36863, 63808-63871, 63922-65535
  Free inodes: 8193-16384

• block bitmap（块对照表）

我们可以通过block bitmap来知道哪些block是空的，此时系统就可以快速地找到可使用空间老放置文件。

• inode bitmap（inode对照表）

这个和block bitmap的功能是类似的，只是inode bitmap记录的是使用与未使用的号码。

• group descriptor

描述每个区段(block group)开始和结束的block号码，以及说明每个区段(inodemap、blockmap、inode table)分别介于哪些block号码之间。

文件及系统空间计算

ext3：

• 单个文件最大大小：

1).ext3文件系统采用32bit的块地址索引空间；
2)在inode条目中，引用一个块空间符号需要4byte的大小；
3)对于一个inode来说，设计了12个直接指针索引，一个间接指针索引，一个双间接指针索引，以及一个三间接指针索引
一个block 为4k：
block总数为：12+256+256256+256256256=12+256+65535+16777216=16,843,019
单个最大文件为：
(16,843,019 * 4k)/（10241024） = 67,372,076‬/1,048,576=64.25101852416992‬G

• 最大分区大小(即文件系统大小)：

在ext3文件系统中，采用32bit的块索引空间，且其采用int的无符号整型，因此一个分区的最大空间为：
2^32*4KByte=16TB

ext读取文件过程：

# ls -ldi / /etc /etc/passwd
      64 dr-xr-xr-x. 17 root root  224 Jun 17  2019 /
16777281 drwxr-xr-x. 75 root root 8192 Mar 21 11:32 /etc
17110256 -rw-r--r--.  1 root root  999 Feb  8 22:59 /etc/passwd

1、访问 “/” inode 检查用户是否有权限访问"/“目录（需要 r、x权限）找到”/“的block
2、查询”/“的block获得”/etc"的inode
3、查询“/etc”inode 检查用户是否有权限访问"/etc"目录（需要 r、x权限）找到"/etc"的block
4、查询"/etc"的block获得"passwd"的inode
5、查询“passwd”文件的inode 检查用户是否有权限访问"passwd"目录（r权限）找到passwd的block。
6、读取passwd的数据

日志

• 日志写入过程

1. 预备：当系统要写入一个文件时，会先在日志记录块中记录某个文件准备要写入的信息。
2. 实际写入：开始写入文件的权限与数据；开始更新meta data的数据。
3. 结束：完成数据与meta data的更新后，在日志记录块当中完成该日志记录。

写入：

1. 对元数据的修改（以块为单位）先记录到日志中（这时的数据应该还在内存）
2. 对文件内容进行相应操作
3. 进行commit操作，表示此次操作完成，日志中的元数据可以生效
4. jbd守护进程定时把日志中的元数据flush到磁盘

删除：

1. 在内存中将inode的数据修改，修改后的inode写入日志
2. 文件数据清空（实际上只是清除指针，可能在上一步已经做完）
3. 日志中append一个commit操作，表示删除操作完成
4. 修改后的inode被jbd守护进程flush到磁盘
   故被删除的文件想要恢复，只能祈祷inode所在块，在之前的日志记录中，被写到了日志中

三种日志模式：
◆data=journal日志模式
日志中记录包括所有改变文件系统的数据和元数据。
它是三种ext3日志模式中最慢的，但它将发生错误的可能性降至最小。
使用“data= journal” 模式要求ext3将每个变化写入文件系统2次、写入日志1次，这将降低文件系统的总性能，但它的确是使用者最心爱的模式。
由于记录了在ext3中元数据和 数据更新情况，当一个系统重新启动的时候，这些日志将起作用。

◆data=ordered日志模式

仅记录改变文件系统的元数据，且溢出文件数据要补充到磁盘中。这是缺省的ext3日志模式。
这种模式降低了在写入文件系统和写入日志之间的冗余，因此速度 较快，虽然文件数据的变化情况并不被记录在日志中，但它们必须做，而且由ext3的daemon程序在与之相关的文件系统元数据变化前执行，即在记录元数 据前要修改文件系统数据，这将稍微降低系统的性能（速度），然而可确保文件系统中的文件数据与相应文件系统的元数据同步。

◆data=writeback日志模式

仅记录改变文件系统的元数据，但根据标准文件系统，写程序仍要将文件数据的变化记录在磁盘上，以保持文件系统一致性。
这是速度最快的ext3日志模 式。因为它只记录元数据的变化，而不需等待与文件数据相关的更新如文件大小、目录信息等情况，对文件数据的更新与记录元数据变化可以不同步，即ext3是 支持异步的日志。 缺陷是当系统关闭时，更新的数据因不能被写入磁盘而出现矛盾，这一点目前尚不能很好解决。

一般来说，inode table与data block称为数据存放区域，至于其他例如super block、block bitmap与inode bitmap等区域就被称为metadata（中间数据）因为super block、inode bitmap及block bitmap的数据是经常变动的，每次添加、删除、编辑时都可能会影响到这个三个部分的数据，一次才会被称为中间数据。

数据不一致状态，在早期的Ext2文件系统中，如果发现这个问题，那么系统在重新启动时候，就会通过Super block当中记录的valid bit与文件系统的state等状态来判断

是否强制进行数据一致性的检查。若有需要检查时则以e2fsck这个程序来进行。但这个检查真的是很费时的，因为要针对meta data 区域与实际数据存放区来进行对比得要搜寻整个文件系统。

磁盘异步操作

所有的数据都得要加载到内存后CPU才能够对该数据进行处理。在编辑文件过程中会频繁地写入磁盘中，但磁盘写入的速度要比内存慢很多很没有效率。
Linux使用异步处理的方式解决这个问题： 当系统加载一个文件到内存后，如果该文件没有被改动过，则在内存区段的文件数据会被设置为（clean）的。但如果内存中的文件数据被更改过了，此时该内存中的数据被设置为Dirty。此时所有的操作都在内存中执行，并没有写入到磁盘中。系统会不定时地将内存中设置为Dirty的数据写回磁盘，以保持磁盘与内存数据的一致性。

系统会将常用的文件数据放置到主存储器的缓冲区，以加速文件系统的读写可以手动使用sync来强迫内存中设置为Dirty的文件写回到磁盘中

若正常关机时，关机命令会主动调用sync来将内存的数据写入到磁盘

若不正常关机，由于数据尚未写到磁盘，重启后可能会花很多时间进行磁盘检验，甚至可能导致文件系统损毁。