ext4文件系统结构分析应用实例--mount/umount文件系统改变了文件系统镜像的哪些数据？

背景

在上一篇博文《构造固定大小的文件并进行格式化的方法》（https://blog.csdn.net/keheinash/article/details/104581785）中，提到创建ext4文件系统镜像是为了用于验证大文件加解密，将格式化后的ext4镜像加密再解密，并将解密后的镜像挂载，发现和未加密前的镜像挂载后的内容是一致的，且两个文件系统下每个文件的内容都是一致的，看起来大文件加解密是成功的。以防万一，顺手用md5sum和shasum检查两个镜像的摘要，结果发现摘要居然不一样了。

一开始以为是文件加解密模块的问题，但是用正常的大文件（非文件系统镜像）进行加解密是完全正常的，无论是肉眼观察文件的内容还是明文和解密结果的摘要，都是一致的。

由于mdssum和shasum只会通过文件内容计算摘要，所以只要文件内容不变，修改文件名、文件访问时间等文件属性（即文件元数据），是不会导致文件的摘要发生变化的，所以可以排除是两个文件系统镜像名字不一致导致的原因。

没有思路，乱敲一通命令的时候发现：对同一个文件系统镜像，将文件系统挂载后，不改变文件系统上任何文件的情况下，文件系统镜像的摘要竟然会发生变化，不改变文件系统上任何文件的情况下，卸载文件系统，文件系统镜像的摘要也会发生变化。

分析

既然每次mount、umount后，ext4文件系统镜像的摘要都会发生变化，说明在mount和umount操作后，文件系统镜像上的数据确实会发生变化。

为了进一步确认，可以用stat命令查看挂载前的文件系统镜像、挂载后的文件系统镜像、卸载后的文件系统镜像

对比stat的结果，发现注意的差别在于Access、Modify、Change，这三个值都表示时间，具体的含义如下图所示

从上图的解释，结合stat对比图，可以确定，mount和umount后文件的内容确实发生了变化，才会导致Modify和Change的值被改变。注意这里说的文件，是文件系统镜像这个文件本身，并不是文件系统镜像里的文件，文件系统镜像本身也是一个文件，只是它存储的01等数据可以被表达或者解释成为文件系统，对于mds5sum和shasum等工具，文件系统镜像这个文件本身和其他普通文件并没有区别。

在mount操作后和umount操作前，我们都没有在挂载目录进行任何操作，甚至连ls都没有执行过，那么这两个操作到底会触发文件系统镜像的哪些数据发生变化呢？

ext4文件系统镜像对比

为了查找mount和umount后，文件系统的镜像发生了哪些变化，最直接的方法就是用bcompare对比这几个文件系统镜像

原始文件系统镜像和mount之后的文件系统镜像的对比

首先，对比最原始的文件系统镜像（即刚格式化出来，没有进行过任何修改、挂载的操作）和mount过后的文件系统镜像，为了进行对比，在mount之前，我们cp一份原始文件系统镜像，改名未used_to_mount，通过shasum命令，可以看到此时这两个文件系统镜像的摘要是一模一样的

现在，我们把used_to_mount挂载到test目录，然后检查used_to_mount的摘要，发现已经较mount之前发生了变化

现在用bcompare工具对比这两个文件系统镜像，直接查看diff的地方，虽然通过bcompare工具确实看到了挂载前后确实有存在差异的地方，但是由于我们对ext4文件系统的结构并不了解，我们并不知道这些有差异的字节有什么样的含义，所以有必要了解ext4文件系统的结构，才能继续分析下去

ext4文件系统结构分析

关于ext4文件系统结构的分析，网上有很多资料，下面几个链接都讲得比较清晰
https://www.cnblogs.com/alantu2018/p/8461272.html
https://www.cnblogs.com/jiangcsu/p/5737659.html

可以看到，ext4文件系统的结构还是比较复杂的，但是通过https://www.cnblogs.com/jiangcsu/p/5737659.html里的这段描述，对比我们上面用bcompare做的对比结果，发现地址都是0x00000438和0x00000439的值都是53和ef，所以bcompare中有差异的这一段可以确认就是ext4文件系统中的超级快（super block）。

那么有差异的这几个值具体代表的是什么意思呢，这就需要结合用于描述超级块的结构体ext4_super_block来分析。

下图的结构体就是用于描述ext4超级块中每个地址的字段代表的含义以及字段的值，结构体左边的注释很贴心地描述了每个字段所在地起始地址，按照左边地地址，可以发现38和39这两个字节，存放地应该是代表ext4文件系统的标志，即53和ef，这个s_magic刚好是16bit的长度，即2字节。

结合上面的结构体描述图，再回到我们的bcompare结果，可以看到，挂载前后有差异的字段分别是：s_mtime、s_wtime、s_mnt_count、s_state，这三个字段分别表示最近一次的挂载时间、最近一次的写操作时间、挂载次数、文件系统状态标志。

s_state为1表示处于未挂载状态，0表示处于挂载状态，出错则为2。original是未挂载前的镜像，因此s_state为1，used_to_mount是挂载后文件系统镜像，因此s_state为0。

s_mnt_count表示挂载次数，original创建后未被挂载，因此该值为0，used_to_mount创建后被挂载了一次，因此该值为1。

s_mtime、s_wtime都是时间戳，通过转换s_mtime得到的时间正是挂载文件系统的时间。

s_wtime的值和s_mtime的值是一样的，因为挂载后并没有在文件系统挂载目录创建/删除过内容，因此对文件系统镜像的修改就是对s_mtime、s_wtime、s_mnt_count、s_state这几个值的修改，这几个值的修改是在挂载的时候修改的，所以最近一次的写操作时间就是最近一次挂载时间。这几个值都是超级块的一部分，超级块是文件系统镜像这个文件的内容，所以文件系统镜像里的内容确实是发生了变化，这也是挂载前后镜像的摘要不一致的原因。

umount后文件系统镜像的变化

根据上面的分析思路，来看看umount后的情况，同样地，为了方便对比，在umount前，需要备份一下已经挂载的文件系统镜像，从下图可以看出，umount后文件系统镜像的摘要马上发生变化

同样地，用bcompare对比挂载前后的文件系统镜像

对比结构体定义，可以看到umount前后存在差异的字段为：s_wtime、s_state、s_volume_name，分别表示最近一次的写操作时间、文件系统状态标志、卷名。
镜像从挂载状态变成未挂载，s_state从0变为1，文件系镜像内容发生变化，s_wtime的时间戳也更新了，至于s_volume_name表示的卷名还不清楚为什么会发生变化，因为我在mount的时候是没有指定卷名的，这个字段在两个文件系统镜像上的差异只有一个字节不同，其他15个字节都是0，所以也不是挂载目录的名字，这个有机会再研究。

用dumpe2fs查看文件系统的信息

如果并不需要具体分析文件系统的哪些字段被修改，只想直观地查看哪些属性发生变化，可以直接使用dumpe2fs工具，这个工具可用于查看ext2/3/4文件系统的信息



用bcompare可以直观地看出哪些数据发生了变化

mount时不改变文件系统镜像内容的方法

有没有办法可以在挂载的时候不改变文件系统镜像的内容呢？即像上面说的超级块等元数据的内容也不让它发生变化，同事建议，可以在mount时加上-r选项，经过测试，加上-r选项后在mount，mount、umount同一个文件系统镜像，其摘要也不会发生变化

经过mount和umount操作后，用dumpe2fs查看文件系统镜像，发现最近一次挂载时间，最近一次写入时间，挂载次数等值都没有发生变化

结论

1.普通的文件是不包含元数据的，所以只要文件的内容不变，即使Access、Modify、Change、文件名、文件所在位置、user、group发生变化，这个文件的摘要还是会不变的。
2.超级块是属于整个文件系统的元数据，一般都存储在文件系统的块组0，属于文件系统镜像内容的一部分，所以只要这部分数据有变化，文件系统镜像的摘要也会发生变化，这也就是挂载文件系统后，没有对挂载目录进行任何操作的情况下，文件系统镜像的摘要会发生变化的原因。
3.mount 的-r选项让文件系统镜像以只读的方式挂载，并不只是限制用户对挂载目录的写入操作，同时也会限制对文件系统镜像存储的元数据的修改，使用-r选项挂载的文件系统镜像，mount和umount操作都不会改变文件系统镜像的内容。