我一頓操做把電腦弄崩了！！！數據全沒了！！！我該怎麼辦？

這是Java建設者的第 78 篇原創長文

文件系統的管理和優化

可以使文件系統工做是一回事，可以使文件系統高效、穩定的工做是另外一回事，下面咱們就來探討一下文件系統的管理和優化。

磁盤空間管理
文件一般存在磁盤中，因此如何管理磁盤空間是一個操做系統的設計者須要考慮的問題。在文件上進行存有兩種策略：「分配 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 編號爲 十、十一、1四、2七、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 同樣困難，所以不多須要手動的磁盤碎片整理。並且，固態硬盤並不受磁盤碎片的影響，事實上，在固態硬盤上作磁盤碎片整理反卻是畫蛇添足，不只沒有提升性能，反而磨損了固態硬盤。因此碎片整理只會縮短固態硬盤的壽命。