背景
在上一篇博文《構造固定大小的文件並進行格式化的方法》（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操作都不會改變文件系統鏡像的內容。