我一頓操作把電腦弄崩了！！！數據全沒了！！！我該怎麼辦？
- 2020 年 3 月 26 日
- 筆記
文件系統的管理和優化
能夠使文件系統工作是一回事，能夠使文件系統高效、穩定的工作是另一回事，下面我們就來探討一下文件系統的管理和優化。
磁碟空間管理
文件通常存在磁碟中，所以如何管理磁碟空間是一個作業系統的設計者需要考慮的問題。在文件上進行存有兩種策略：「分配 n 個位元組的連續磁碟空間；或者把文件拆分成多個並不一定連續的塊」。在存儲管理系統中，主要有分段管理和 分頁管理 兩種方式。
正如我們所看到的，按連續位元組序列存儲文件有一個明顯的問題，當文件擴大時，有可能需要在磁碟上移動文件。記憶體中分段也有同樣的問題。不同的是，相對於把文件從磁碟的一個位置移動到另一個位置，記憶體中段的移動操作要快很多。因此，幾乎所有的文件系統都把文件分割成固定大小的塊來存儲。
塊大小
一旦把文件分為固定大小的塊來存儲，就會出現問題，塊的大小是多少？按照「磁碟組織方式，扇區、磁軌和柱面顯然都可以作為分配單位」。在分頁系統中，分頁大小也是主要因素。
擁有大的塊尺寸意味著每個文件，甚至 1 位元組文件，都要佔用一個柱面空間，也就是說小文件浪費了大量的磁碟空間。另一方面，小塊意味著大部分文件將會跨越多個塊，因此需要多次搜索和旋轉延遲才能讀取它們，從而降低了性能。因此，如果分配的塊太大會浪費空間；分配的塊太小會浪費時間。
記錄空閑塊
一旦指定了塊大小，下一個問題就是怎樣跟蹤空閑塊。有兩種方法被廣泛採用，如下圖所示
第一種方法是採用磁碟塊鏈表，鏈表的每個塊中包含極可能多的空閑磁碟塊號。對於 1 KB 的塊和 32 位的磁碟塊號，空閑表中每個塊包含有 255 個空閑的塊號。考慮 1 TB 的硬碟，擁有大概十億個磁碟塊。為了存儲全部地址塊號，如果每塊可以保存 255 個塊號，則需要將近 400 萬個塊。通常，空閑塊用於保存空閑列表，因此存儲基本上是空閑的。
另一種空閑空間管理的技術是點陣圖(bitmap)，n 個塊的磁碟需要 n 位點陣圖。在點陣圖中，空閑塊用 1 表示，已分配的塊用 0 表示。對於 1 TB 硬碟的例子，需要 10 億位表示，即需要大約 130 000 個 1 KB 塊存儲。很明顯，和 32 位鏈表模型相比，點陣圖需要的空間更少，因為每個塊使用 1 位。只有當磁碟快滿的時候，鏈表需要的塊才會比點陣圖少。
如果空閑塊是長期連續的話，那麼空閑列表可以改成記錄連續分塊而不是單個的塊。每個塊都會使用 8位、16位、32 位的計數來與每個塊相聯，來記錄連續空閑塊的數量。最好的情況是一個空閑塊可以用兩個數字來表示：「第一個空閑塊的地址和空閑塊的計數」。另一方面，如果磁碟嚴重碎片化，那麼跟蹤連續分塊要比跟蹤單個分塊運行效率低，因為不僅要存儲地址，還要存儲數量。
❝這種情況說明了一個作業系統設計者經常遇到的一個問題。有許多數據結構和演算法可以用來解決問題，但是選擇一個
最好的方案需要數據的支援，而這些數據是設計者無法預先擁有的。只有在系統部署完畢真正使用使用後才會獲得。 ❞
現在，回到空閑鏈表的方法，只有一個指針塊保存在記憶體中。創建文件時，所需要的塊從指針塊中取出。當它用完時，將從磁碟中讀取一個新的指針塊。類似地，刪除文件時，文件的塊將被釋放並添加到主存中的指針塊中。當塊被填滿時，寫回磁碟。
在某些特定的情況下，這個方法導致了不必要的磁碟 IO，如下圖所示
上面記憶體中的指針塊僅有兩個空閑塊，如果釋放了一個含有三個磁碟塊的文件，那麼該指針塊就會溢出，必須將其寫入磁碟，那麼就會產生如下圖的這種情況。
如果現在寫入含有三個塊的文件，已滿的指針不得不再次讀入，這將會回到上圖 a 中的情況。如果有三個塊的文件只是作為臨時文件被寫入，在釋放它時，需要進行另一次磁碟寫操作以將完整的指針塊寫回到磁碟。簡而言之，當指針塊幾乎為空時，一系列短暫的臨時文件可能會「導致大量磁碟 I/O」。
避免大部分磁碟 I/O 的另一種方法是拆分完整的指針塊。這樣，當釋放三個塊時，變化不再是從 a – b，而是從 a – c，如下圖所示
現在，系統可以處理一系列臨時文件，而不需要進行任何磁碟 I/O。如果記憶體中指針塊滿了，就寫入磁碟，半滿的指針塊從磁碟中讀入。這裡的思想是：要保持磁碟上的大多數指針塊為滿的狀態（減少磁碟的使用），但是在記憶體中保留了一個半滿的指針塊。這樣，就可以既處理文件的創建又同時可以處理文件的刪除操作，而不會為空閑表進行磁碟 I/O。
對於點陣圖，會在記憶體中只保留一個塊，只有在該塊滿了或空了的情形下，才到磁碟上取另一個塊。通過在點陣圖的單一塊上進行所有的分配操作，磁碟塊會緊密的聚集在一起，從而減少了磁碟臂的移動。由於點陣圖是一種固定大小的數據結構，所以如果內核是分頁的，就可以把點陣圖放在虛擬記憶體中，在需要時將點陣圖的頁面調入。
磁碟配額
為了防止一些用戶佔用太多的磁碟空間，多用戶操作通常提供一種磁碟配額(enforcing disk quotas)的機制。系統管理員為每個用戶分配「最大的文件和塊分配」，並且作業系統確保用戶不會超過其配額。我們下面會談到這一機制。
在用戶打開一個文件時，作業系統會找到文件屬性和磁碟地址，並把它們送入記憶體中的打開文件表。其中一個屬性告訴文件所有者是誰。任何有關文件的增加都會記到所有者的配額中。
第二張表包含了每個用戶當前打開文件的配額記錄，即使是其他人打開該文件也一樣。如上圖所示，該表的內容是從被打開文件的所有者的磁碟配額文件中提取出來的。當所有文件關閉時，該記錄被寫回配額文件。
當在打開文件表中建立一新表項時，會產生一個指向所有者配額記錄的指針。每次向文件中添加一個塊時，文件所有者所用數據塊的總數也隨之增加，並會同時增加硬限制和軟限制的檢查。可以超出軟限制，但硬限制不可以超出。當已達到硬限制時，再往文件中添加內容將引發錯誤。同樣，對文件數目也存在類似的檢查。
❝什麼是硬限制和軟限制？「硬限制是軟限制的上限」。軟限制是為會話或進程實際執行的限制。這允許管理員（或用戶）將硬限制設置為允許它們希望允許的最大使用上限。然後，其他用戶和進程可以根據需要使用軟限制將其資源使用量自限制到更低的上限。 ❞
當一個用戶嘗試登陸，系統將檢查配額文件以查看用戶是否超出了文件數量或磁碟塊數量的軟限制。如果違反了任一限制，則會顯示警告，保存的警告計數減 1，如果警告計數為 0 ，表示用戶多次忽略該警告，因而將不允許該用戶登錄。要想再得到登錄的許可，就必須與系統管理員協商。
如果用戶在退出系統時消除所超過的部分，他們就可以再一次終端會話期間超過其軟限制，但「無論什麼情況下都不會超過硬限制」。
文件系統備份
文件系統的毀壞要比電腦的損壞嚴重很多。無論是硬體還是軟體的故障，只要電腦文件系統被破壞，要恢復起來都是及其困難的，甚至是不可能的。因為文件系統無法抵禦破壞，因而我們要在文件系統在被破壞之前做好數據備份，但是備份也不是那麼容易，下面我們就來探討備份的過程。
許多人認為為文件系統做備份是不值得的，並且很浪費時間，直到有一天他們的磁碟壞了，他們才意識到事情的嚴重性。相對來說，公司在這方面做的就很到位。磁帶備份主要要處理好以下兩個潛在問題中的一個
- 從意外的災難中恢復
這個問題主要是由於外部條件的原因造成的，比如磁碟破裂，水災火災等。
- 從錯誤的操作中恢復
第二個問題通常是由於用戶意外的刪除了原本需要還原的文件。這種情況發生的很頻繁，使得 Windows 的設計者們針對 刪除 命令專門設計了特殊目錄，這就是 回收站(recycle bin)，也就是說，在刪除文件的時候，文件本身並不真正從磁碟上消失，而是被放置到這個特殊目錄下，等以後需要的時候可以還原回去。文件備份更主要是指這種情況，能夠允許幾天之前，幾周之前的文件從原來備份的磁碟進行還原。
做文件備份很耗費時間而且也很浪費空間，這會引起下面幾個問題。首先，是要「備份整個文件還是僅備份一部分呢」？一般來說，只是備份特定目錄及其下的全部文件，而不是備份整個文件系統。
其次，對上次未修改過的文件再進行備份是一種浪費，因而產生了一種增量轉儲(incremental dumps) 的思想。最簡單的增量轉儲的形式就是周期性的做全面的備份，而每天只對增量轉儲完成後發生變化的文件做單個備份。
❝周期性：比如一周或者一個月 ❞
稍微好一點的方式是只備份最近一次轉儲以來更改過的文件。當然，這種做法極大的縮減了轉儲時間，但恢復起來卻更複雜，因為「最近的全面轉儲先要全部恢復，隨後按逆序進行增量轉儲」。為了方便恢復，人們往往使用更複雜的轉儲模式。
第三，既然待轉儲的往往是海量數據，那麼在將其寫入磁帶之前對文件進行壓縮就很有必要。但是，如果在備份過程中出現了文件損壞的情況，就會導致破壞壓縮演算法，從而使整個磁帶無法讀取。所以在備份前是否進行文件壓縮需慎重考慮。
第四，對正在使用的文件系統做備份是很難的。如果在轉儲過程中要添加，刪除和修改文件和目錄，則轉儲結果可能不一致。因此，因為轉儲過程中需要花費數個小時的時間，所以有必要在晚上將系統離線進行備份，然而這種方式的接受程度並不高。所以，人們修改了轉儲演算法，記下文件系統的瞬時快照，即複製關鍵的數據結構，然後需要把將來對文件和目錄所做的修改複製到塊中，而不是到處更新他們。
磁碟轉儲到備份磁碟上有兩種方案：「物理轉儲和邏輯轉儲」。物理轉儲(physical dump) 是從磁碟的 0 塊開始，依次將所有磁碟塊按照順序寫入到輸出磁碟，並在複製最後一個磁碟時停止。這種程式的萬無一失性是其他程式所不具備的。
第二個需要考慮的是「壞塊的轉儲」。製造大型磁碟而沒有瑕疵是不可能的，所以也會存在一些壞塊(bad blocks)。有時進行低級格式化後，壞塊會被檢測出來並進行標記，這種情況的解決辦法是用磁碟末尾的一些空閑塊所替換。
然而，一些塊在格式化後會變壞，在這種情況下作業系統可以檢測到它們。通常情況下，它可以通過創建一個由所有壞塊組成的文件來解決問題，確保它們不會出現在空閑池中並且永遠不會被分配。「那麼此文件是完全不可讀的」。如果磁碟控制器將所有的壞塊重新映射，物理轉儲還是能夠正常工作的。
Windows 系統有分頁文件(paging files) 和 休眠文件(hibernation files) 。它們在文件還原時不發揮作用，同時也不應該在第一時間進行備份。
物理轉儲和邏輯轉儲
物理轉儲的主要優點是簡單、極為快速（基本上是以磁碟的速度運行），缺點是全量備份，不能跳過指定目錄，也不能增量轉儲，也不能恢復個人文件的請求。因此句「大多數情況下不會使用物理轉儲，而使用邏輯轉儲」。
邏輯轉儲(logical dump)從一個或幾個指定的目錄開始，遞歸轉儲自指定日期開始後更改的文件和目錄。因此，在邏輯轉儲中，轉儲磁碟上有一系列經過仔細識別的目錄和文件，這使得根據請求輕鬆還原特定文件或目錄。
既然邏輯轉儲是最常用的方式，那麼下面就讓我們研究一下邏輯轉儲的通用演算法。此演算法在 UNIX 系統上廣為使用，如下圖所示
待轉儲的文件系統，其中方框代表目錄，圓圈代表文件。黃色的項目表是自上次轉儲以來修改過。每個目錄和文件都被標上其 inode 號。
此演算法會轉儲位於修改文件或目錄路徑上的所有目錄（也包括未修改的目錄），原因有兩個。第一是能夠在不同電腦的文件系統中恢復轉儲的文件。通過這種方式，轉儲和重新存儲的程式能夠用來在兩個電腦之間傳輸整個文件系統。第二個原因是能夠對單個文件進行增量恢復。
邏輯轉儲演算法需要維持一個 inode 為索引的點陣圖(bitmap)，每個 inode 包含了幾位。隨著演算法的進行，點陣圖中的這些位會被設置或清除。演算法的執行分成四個階段。第一階段從起始目錄（本例為根目錄）開始檢查其中所有的目錄項。對每一個修改過的文件，該演算法將在點陣圖中標記其 inode。演算法還會標記並遞歸檢查每一個目錄（不管是否修改過）。
在第一階段結束時，所有修改過的文件和全部目錄都在點陣圖中標記了，如下圖所示
理論上來說，第二階段再次遞歸遍歷目錄樹，並去掉目錄樹中任何不包含被修改過的文件或目錄的標記。本階段執行的結果如下
注意，inode 編號為 10、11、14、27、29 和 30 的目錄已經被去掉了標記，因為它們所包含的內容沒有修改。它們也不會轉儲。相反，inode 編號為 5 和 6 的目錄本身儘管沒有被修改過也要被轉儲，因為在新的機器上恢復當日的修改時需要這些資訊。為了提高演算法效率，可以將這兩階段的目錄樹遍歷合二為一。
現在已經知道了哪些目錄和文件必須被轉儲了，這就是上圖 b 中標記的內容，第三階段演算法將以節點號為序，掃描這些 inode 並轉儲所有標記為需轉儲的目錄，如下圖所示
為了進行恢復，每個被轉儲的目錄都用目錄的屬性（所有者、時間）作為前綴。
最後，在第四階段，上圖中被標記的文件也被轉儲，同樣，由其文件屬性作為前綴。至此，轉儲結束。
從轉儲磁碟上還原文件系統非常簡單。一開始，需要在磁碟上創建空文件系統。然後恢復最近一次的完整轉儲。由於磁帶上最先出現目錄，所以首先恢複目錄，給出文件系統的框架(skeleton)，然後恢復文件系統本身。在完整存儲之後是第一次增量存儲，然後是第二次重複這一過程，以此類推。
儘管邏輯存儲十分簡單，但是也會有一些棘手的問題。首先，既然空閑塊列表並不是一個文件，那麼在所有被轉儲的文件恢復完畢之後，就需要從零開始重新構造。
另外一個問題是關於鏈接。如果文件鏈接了兩個或者多個目錄，而文件只能還原一次，那麼並且所有指向該文件的目錄都必須還原。
還有一個問題是，UNIX 文件實際上包含了許多 空洞(holes)。打開文件，寫幾個位元組，然後找到文件中偏移了一定距離的地址，又寫入更多的位元組，這麼做是合法的。但兩者之間的這些塊並不屬於文件本身，從而也不應該在其上進行文件轉儲和恢復。
最後，無論屬於哪一個目錄，「特殊文件，命名管道以及類似的文件」都不應該被轉儲。
文件系統的一致性
影響可靠性的一個因素是文件系統的一致性。許多文件系統讀取磁碟塊、修改磁碟塊、再把它們寫回磁碟。如果系統在所有塊寫入之前崩潰，文件系統就會處於一種不一致(inconsistent)的狀態。如果某些尚未寫回的塊是索引節點塊，目錄塊或包含空閑列表的塊，則此問題是很嚴重的。
為了處理文件系統一致性問題，大部分電腦都會有應用程式來檢查文件系統的一致性。例如，UNIX 有 fsck；Windows 有 sfc，每當引導系統時（尤其是在崩潰後），都可以運行該程式。
可以進行兩種一致性檢查：「塊的一致性檢查和文件的一致性檢查」。為了檢查塊的一致性，應用程式會建立兩張表，每個包含一個計數器的塊，最初設置為 0 。第一個表中的計數器跟蹤該塊在文件中出現的次數，第二張表中的計數器記錄每個塊在空閑列表、空閑點陣圖中出現的頻率。
然後檢驗程式使用原始設備讀取所有的 inode，忽略文件的結構，只返回從零開始的所有磁碟塊。從 inode 開始，很容易找到文件中的塊數量。每當讀取一個塊時，該塊在第一個表中的計數器 + 1，應用程式會檢查空閑塊或者點陣圖來找到沒有使用的塊。空閑列表中塊的每次出現都會導致其在第二表中的計數器增加。
如果文件系統一致，則每一個塊或者在第一個表計數器為 1，或者在第二個表計數器中為 1，如下圖所示
但是當系統崩潰後，這兩張表可能如下所示
其中，磁碟塊 2 沒有出現在任何一張表中，這稱為 塊丟失(missing block)。儘管塊丟失不會造成實際的損害，但它的確浪費了磁碟空間，減少了磁碟容量。塊丟失的問題很容易解決，文件系統檢驗程式把他們加到空閑表中即可。
有可能出現的另外一種情況如下所示
其中，塊 4 在空閑表中出現了 2 次。這種解決方法也很簡單，只要重新建立空閑表即可。
最糟糕的情況是在兩個或者多個文件中出現同一個數據塊，如下所示
比如上圖的磁碟塊 5，如果其中一個文件被刪除，塊 5 會被添加到空閑表中，導致一個塊同時處於使用和空閑的兩種狀態。如果刪除這兩個文件，那麼在空閑表中這個磁碟塊會出現兩次。
文件系統檢驗程式採取的處理方法是，先分配一磁碟塊，把塊 5 中的內容複製到空閑塊中，然後把它插入到其中一個文件中。這樣文件的內容未改變，雖然這些內容可以肯定是不對的，但至少保證了文件的一致性。這一錯誤應該報告給用戶，由用戶檢查受檢情況。
除了檢查每個磁碟塊計數的正確性之外，文件系統還會檢查目錄系統。這時候會用到一張計數器表，但這時是一個文件（而不是一個塊）對應於一個計數器。程式從根目錄開始檢驗，沿著目錄樹向下查找，檢查文件系統的每個目錄。對每個目錄中的文件，使其計數 + 1。
❝注意，由於存在硬連接，一個文件可能出現在兩個或多個目錄中。而遇到符號鏈接是不計數的，不會對目標文件的計數器 + 1。 ❞
在檢驗程式完成後，會得到一張由 inode 索引的表，說明每個文件和目錄的包含關係。檢驗程式會將這些數字與存儲在文件 inode 中的鏈接數目做對比。如果 inode 節點的鏈接計數大於目錄項個數，這時即使所有文件從目錄中刪除，這個計數仍然不是 0 ，inode 不會被刪除。這種錯誤不嚴重，卻因為存在不屬於任何目錄的文件而浪費了磁碟空間。
另一種錯誤則是潛在的風險。如果同一個文件鏈接兩個目錄項，但是 inode 鏈接計數只為 1，如果刪除了任何一個目錄項，對應 inode 鏈接計數變為 0。當 inode 計數為 0 時，文件系統標誌 inode 為 未使用，並釋放全部的塊。這會導致其中一個目錄指向未使用的 inode，而很有可能其塊馬上就被分配給其他文件。
文件系統性能
訪問磁碟的效率要比記憶體慢的多，是時候又祭出這張圖了
從記憶體讀一個 32 位字大概是 10ns，從硬碟上讀的速率大概是 100MB/S，對每個 32 位字來說，效率會慢了四倍，另外，還要加上 5 – 10 ms 的尋道時間等其他損耗，如果只訪問一個字，記憶體要比磁碟快百萬數量級。所以磁碟優化是很有必要的，下面我們會討論幾種優化方式
高速快取
最常用的減少磁碟訪問次數的技術是使用 塊高速快取(block cache) 或者 緩衝區高速快取(buffer cache)。高速快取指的是一系列的塊，它們在邏輯上屬於磁碟，但實際上基於性能的考慮被保存在記憶體中。
管理高速快取有不同的演算法，常用的演算法是：檢查全部的讀請求，查看在高速快取中是否有所需要的塊。如果存在，可執行讀操作而無須訪問磁碟。如果檢查塊不再高速快取中，那麼首先把它讀入高速快取，再複製到所需的地方。之後，對同一個塊的請求都通過高速快取來完成。
高速快取的操作如下圖所示
由於在高速快取中有許多塊，所以需要某種方法快速確定所需的塊是否存在。常用方法是將設備和磁碟地址進行散列操作，然後，在散列表中查找結果。具有相同散列值的塊在一個鏈表中連接在一起（這個數據結構是不是很像 HashMap?），這樣就可以沿著衝突鏈查找其他塊。
如果高速快取已滿，此時需要調入新的塊，則要把原來的某一塊調出高速快取，如果要調出的塊在上次調入後已經被修改過，則需要把它寫回磁碟。這種情況與分頁非常相似，所有常用的頁面置換演算法我們之前已經介紹過，如果有不熟悉的小夥伴可以參考 https://mp.weixin.qq.com/s/5-k2BJDgEp9symxcSwoprw。比如 「FIFO 演算法、第二次機會演算法、LRU 演算法、時鐘演算法、老化演算法等」。它們都適用於高速快取。
塊提前讀
第二個明顯提高文件系統的性能是，在需要用到塊之前，試圖提前將其寫入高速快取，從而提高命中率。許多文件都是順序讀取。如果請求文件系統在某個文件中生成塊 k，文件系統執行相關操作並且在完成之後，會檢查高速快取，以便確定塊 k + 1 是否已經在高速快取。如果不在，文件系統會為 k + 1 安排一個預讀取，因為文件希望在用到該塊的時候能夠直接從高速快取中讀取。
當然，塊提前讀取策略只適用於實際順序讀取的文件。對隨機訪問的文件，提前讀絲毫不起作用。甚至還會造成阻礙。
減少磁碟臂運動
高速快取和塊提前讀並不是提高文件系統性能的唯一方法。另一種重要的技術是「把有可能順序訪問的塊放在一起，當然最好是在同一個柱面上，從而減少磁碟臂的移動次數」。當寫一個輸出文件時，文件系統就必須按照要求一次一次地分配磁碟塊。如果用點陣圖來記錄空閑塊，並且整個點陣圖在記憶體中，那麼選擇與前一塊最近的空閑塊是很容易的。如果用空閑表，並且鏈表的一部分存在磁碟上，要分配緊鄰的空閑塊就會困難很多。
不過，即使採用空閑表，也可以使用 塊簇 技術。即不用塊而用連續塊簇來跟蹤磁碟存儲區。如果一個扇區有 512 個位元組，有可能系統採用 1 KB 的塊（2 個扇區），但卻按每 2 塊（4 個扇區）一個單位來分配磁碟存儲區。這和 2 KB 的磁碟塊並不相同，因為在高速快取中它仍然使用 1 KB 的塊，磁碟與記憶體數據之間傳送也是以 1 KB 進行，但在一個空閑的系統上順序讀取這些文件，尋道的次數可以減少一半，從而使文件系統的性能大大改善。若考慮旋轉定位則可以得到這類方法的變體。在分配塊時，系統盡量把一個文件中的連續塊存放在同一個柱面上。
在使用 inode 或任何類似 inode 的系統中，另一個性能瓶頸是，讀取一個很短的文件也需要兩次磁碟訪問：「一次是訪問 inode，一次是訪問塊」。通常情況下，inode 的放置如下圖所示
其中，全部 inode 放在靠近磁碟開始位置，所以 inode 和它所指向的塊之間的平均距離是柱面組的一半，這將會需要較長時間的尋道時間。
一個簡單的改進方法是，在磁碟中部而不是開始處存放 inode ，此時，在 inode 和第一個塊之間的尋道時間減為原來的一半。另一種做法是：將磁碟分成多個柱面組，每個柱面組有自己的 inode，數據塊和空閑表，如上圖 b 所示。
當然，只有在磁碟中裝有磁碟臂的情況下，討論尋道時間和旋轉時間才是有意義的。現在越來越多的電腦使用 固態硬碟(SSD)，對於這些硬碟，由於採用了和快閃記憶體同樣的製造技術，使得隨機訪問和順序訪問在傳輸速度上已經較為相近，傳統硬碟的許多問題就消失了。但是也引發了新的問題。
磁碟碎片整理
在初始安裝作業系統後，文件就會被不斷的創建和清除，於是磁碟會產生很多的碎片，在創建一個文件時，它使用的塊會散布在整個磁碟上，降低性能。刪除文件後，回收磁碟塊，可能會造成空穴。
磁碟性能可以通過如下方式恢復：移動文件使它們相互挨著，並把所有的至少是大部分的空閑空間放在一個或多個大的連續區域內。Windows 有一個程式 defrag 就是做這個事兒的。Windows 用戶會經常使用它，SSD 除外。
磁碟碎片整理程式會在讓文件系統上很好地運行。Linux 文件系統（特別是 ext2 和 ext3）由於其選擇磁碟塊的方式，在磁碟碎片整理上一般不會像 Windows 一樣困難，因此很少需要手動的磁碟碎片整理。而且，固態硬碟並不受磁碟碎片的影響，事實上，在固態硬碟上做磁碟碎片整理反倒是多此一舉，不僅沒有提高性能，反而磨損了固態硬碟。所以碎片整理只會縮短固態硬碟的壽命。
往期精選
記憶體：你跑慢點行不行？CPU：跑慢點你養我嗎？記憶體：我不管！
相關參考：
https://zhuanlan.zhihu.com/p/41358013
https://www.linuxtoday.com/blog/what-is-an-inode.html
https://www.lifewire.com/what-is-fragmentation-defragmentation-2625884
https://www.geeksforgeeks.org/free-space-management-in-operating-system/
https://sites.ualberta.ca/dept/chemeng/AIX-43/share/man/info/C/a_doc_lib/aixprggd/genprogc/fsyslayout.htm
https://en.wikipedia.org/wiki/Disk_partitioning
https://en.wikipedia.org/wiki/Master_boot_record
https://en.wikipedia.org/wiki/Booting
https://www.computerhope.com/jargon/f/fileprot.htm
https://en.wikipedia.org/wiki/File_attribute
https://en.wikipedia.org/wiki/Make_(software)
https://unix.stackexchange.com/questions/60034/what-are-character-special-and-block-special-files-in-a-unix-system
https://www.computerhope.com/jargon/d/director.htm
https://www.computerhope.com/jargon/r/regular-file.htm
https://baike.baidu.com/item/固態硬碟/453510?fr=aladdin
《現代作業系統》第四版
《Modern Operation System》fourth## 文件系統的管理和優化
