2026年01月09日玄貓（BlackCat）

Linux 儲存架構：從基礎分割到 LVM 彈性管理

本文闡述 Linux 環境下的儲存空間管理策略，從基礎的 fdisk 磁碟分割實踐開始，詳解主分割區、延伸分割區與邏輯分割區的建立與配置。進而探討如何為不同分割區設定特定類型，如 Linux、Swap 與 LVM，並建立對應的檔案系統。文章的核心聚焦於邏輯磁碟管理（LVM）的優勢，說明其如何透過物理卷、磁碟區群組與邏輯磁碟區的架構，實現彈性的空間分配與線上調整，從而克服傳統分割的僵化限制，打造可擴展且易於維護的現代儲存架構。

系統管理儲存技術

磁碟分割 LVM 檔案系統 Linux fdisk 系統管理

在現代資訊系統中，儲存架構的設計直接影響系統的穩定性、效能與未來的擴展潛力。傳統的磁碟分割方法，如主分割區與延伸分割區的劃分，雖然提供了基礎的空間隔離，但在面對動態變化的業務需求時，其固有的僵化性常成為管理瓶頸。本文將從底層的磁碟操作出發，逐步解析如何透過 fdisk 工具進行精確的空間配置，並探討不同檔案系統類型的選擇考量。接著，文章將重點轉向邏輯磁碟管理（LVM）技術，闡述其如何將離散的物理儲存抽象化為統一且具彈性的資源池。透過對物理卷、磁碟區群組與邏輯磁碟區的深入剖析，我們將揭示 LVM 在實現線上空間調整、資料快照與跨裝置整合方面的核心價值，為建構高可用性與可維護性的儲存解決方案提供理論基礎。

儲存空間配置策略與實踐

在處理儲存裝置時，特別是當面臨空間不足的挑戰時，精確的分割與配置是關鍵。當現有分割區已滿，進一步的擴展將會耗盡所有可用的磁碟空間。其中，sdb5 和 sdb6 這兩個分割區的空間實際上是從延伸分割區（extended partition）中劃分出來的，這意味著我們仍有充裕的空間來建立新的分割區。

在進行任何操作前，請確保已插入外部儲存裝置，並確認其裝置名稱，在本文的範例中，我們將其標示為 /dev/sdb。同時，務必卸載（unmount）任何在裝置插入時可能自動掛載的分割區，以避免操作衝突。

初始清理與分割區建立

為了確保一個乾淨的起始點，建議先清除裝置上的現有分割表。這可以透過以下指令完成：

dd if=/dev/zero of=/dev/sd<裝置代號> bs=1M count=100

請務必謹慎確認 <裝置代號>，錯誤的目標可能導致作業系統的損毀。完成初始清理後，我們將著手建立新的分割區。

分割區配置細節

接下來，我們將使用 fdisk 工具來建立六個新的分割區。在指定分割區大小時，請記得在數字前加上加號 (+)，並明確標示單位，例如 +5G 表示建立一個 5 Gigabyte 的分割區，或 +1024M 表示 1024 Megabyte。若省略單位，fdisk 會將數值視為磁區（sectors），可能導致預期外的結果。

fdisk /dev/sdb

進入 fdisk 環境後，執行以下步驟：

建立第一個主分割區：
- 輸入 n 以建立新分割區。
- 選擇 p 以建立主分割區（primary partition）。
- 指定分割區編號為 1。
- 接受預設的起始磁區。
- 輸入 +5G 來指定分割區大小為 5 GiB。此時會建立一個標示為「Linux」類型的分割區。
建立第二個主分割區：
- 再次輸入 n。
- 選擇 p。
- 指定分割區編號為 2。
- 接受預設的起始磁區。
- 輸入 +5G 來建立另一個 5 GiB 的分割區。
建立第三個主分割區：
- 輸入 n。
- 選擇 p。
- 指定分割區編號為 3。
- 接受預設的起始磁區。
- 輸入 +3G 來建立一個 3 GiB 的分割區。
建立延伸分割區：
- 輸入 n。
- 在此階段，由於主分割區已達上限（4個），選擇 e 來建立延伸分割區（extended partition）。
- 接受預設的起始磁區。
- 按下 Enter 鍵接受預設的結束磁區，這將會佔用剩餘的可用空間，建立一個約 101.6 GiB 的延伸分割區。
建立第一個邏輯分割區：
- 輸入 n。
- 系統會提示「All primary partitions are in use.」，並自動進入建立邏輯分割區的模式。
- 接受預設的起始磁區。
- 輸入 +3G 來建立一個 3 GiB 的邏輯分割區，其編號將為 5。
建立第二個邏輯分割區：
- 輸入 n。
- 接受預設的起始磁區。
- 輸入 +4G 來建立一個 4 GiB 的邏輯分割區，其編號將為 6。

在完成所有分割區的定義後，輸入 p 來檢視分割區配置。此時應能看到 sdb1, sdb2, sdb3 這三個主分割區，以及 sdb4 作為延伸分割區。同時，sdb5 和 sdb6 作為邏輯分割區，其空間應包含在 sdb4 的範圍內。

儲存裝置配置架構圖

此圖示展示了儲存裝置 /dev/sdb 的邏輯分割結構，其中包含三個主分割區以及一個延伸分割區，延伸分割區內又劃分出兩個邏輯分割區。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

rectangle "/dev/sdb" {
  rectangle "Partition 1 (Primary)" as P1
  rectangle "Partition 2 (Primary)" as P2
  rectangle "Partition 3 (Primary)" as P3
  rectangle "Partition 4 (Extended)" as E4 {
    rectangle "Partition 5 (Logical)" as L5
    rectangle "Partition 6 (Logical)" as L6
  }
}

P1 -- "/dev/sdb"
P2 -- "/dev/sdb"
P3 -- "/dev/sdb"
E4 -- "/dev/sdb"
L5 -- E4
L6 -- E4

@enduml

看圖說話：

此圖示描繪了 /dev/sdb 儲存裝置的分割區結構。最外層的方塊代表整個裝置 /dev/sdb。其中，Partition 1、Partition 2 和 Partition 3 是直接建立在裝置上的主分割區，它們各自獨立。Partition 4 被定義為延伸分割區，它的主要作用是作為一個容器，用來容納更多的邏輯分割區，這使得我們可以突破主分割區數量的限制。在此延伸分割區 Partition 4 內部，又進一步劃分出 Partition 5 和 Partition 6 這兩個邏輯分割區。這種結構的優勢在於，當需要更多分割區時，可以透過延伸分割區來擴展，而無需重新規劃整個磁碟的配置。這種配置方式在早期磁碟分割表中非常常見，用於最大化分割區的靈活性。

實際應用與風險評估

在進行磁碟分割的過程中，最關鍵的步驟是將變更寫入磁碟。此操作通常透過 w 指令完成。在執行此指令前，務必仔細檢查所有配置，確保分割區的大小、類型和順序均符合預期。一旦寫入，分割表的變更就無法輕易撤銷。

風險考量：

資料損毀：若選錯目標裝置，例如將 dd 指令的輸出指向系統硬碟，將會導致作業系統及所有資料的永久遺失。
分割區配置錯誤：不正確的大小設定或分割區類型可能導致日後無法掛載或使用，甚至影響系統的穩定性。
空間分配不均：若對各分割區的預期用途沒有清晰的規劃，可能導致某些分割區很快就塞滿，而其他分割區卻閒置。

實務建議：

備份：在進行任何磁碟操作前，務必備份所有重要資料。
驗證：在寫入變更前，多次檢查 fdisk 的輸出，確認分割區資訊無誤。
命名與標籤：為分割區設定有意義的標籤（label），例如使用 e2label 或 xfs_admin，有助於日後識別和管理。
檔案系統選擇：根據分割區的用途，選擇合適的檔案系統（如 ext4, XFS, Btrfs），並在分割區建立後進行格式化。

未來發展與優化

隨著儲存技術的演進，如 LVM (Logical Volume Management) 等更靈活的儲存管理方案提供了動態調整分割區大小、快照功能以及更強的容錯能力。對於需要高度彈性與擴展性的應用場景，考慮採用 LVM 架構將能更有效地管理儲存資源，避免因固定分割區大小帶來的限制。此外，SSD 的普及也使得分割區的效能考量更為重要，合理的分割與檔案系統選擇能進一步提升讀寫效能。

儲存架構的智慧佈局與彈性擴展

在現代資訊系統的建構中，儲存空間的規劃與管理是維持系統穩定運行與效能的關鍵環節。從底層的磁碟分割到高階的邏輯磁碟管理，每一個環節都蘊含著深遠的技術考量。本文旨在闡述如何透過精確的磁碟分割策略，並結合彈性的邏輯磁碟管理（LVM）技術，打造一個能夠應對未來擴展需求，同時確保資料安全與系統效能的儲存架構。

磁碟分割的細緻劃分與類型選擇

磁碟分割的過程，如同為數位資產劃分不同的倉儲區域，每個區域都應根據其預期用途來設定最適宜的檔案系統類型。以一個名為 /dev/sdb 的儲存裝置為例，我們可以進行一系列的分割操作，以滿足不同的系統需求。

首先，我們需要定義各個分割區的起始與結束區塊，進而決定其容量。例如，我們可以劃分出 /dev/sdb1 和 /dev/sdb2，各自設定為 5GB 的大小。接著，根據實際需求，我們可以調整分割區的類型代碼（Hex code），以指定其用途。預設的「Linux」類型（代碼 83）適合存放常規的系統檔案與應用程式。然而，系統運行時常需要專門的空間來處理記憶體交換，這時便可將某個分割區（例如 /dev/sdb2）的類型變更為「Linux swap / Solaris」（代碼 82），以供作業系統作為虛擬記憶體使用。

除了系統核心功能，現代儲存架構也常需要支援不同的檔案系統格式。例如，為了與其他作業系統或特定應用程式的相容性，我們可能會將某個分割區（如 /dev/sdb5）設定為「W95 FAT32 (LBA)」（代碼 c）。同時，為了實現更靈活的儲存管理，例如用於建立 RAID 陣列或進行更細緻的磁碟空間分配，我們可以使用「Linux LVM」（代碼 8e）類型，將分割區準備作為邏輯磁碟管理系統的基礎。

在完成所有分割區的類型設定後，透過 p 指令檢查分割表，確認所有設定均符合預期。一旦確認無誤，便執行 w 指令將變更寫入磁碟。此時，系統核心仍在使用舊的分割表，新的配置將在下次重新啟動後生效。為了確保系統能夠立即辨識新的分割結構，可以執行 partprobe /dev/sdb 命令，或直接重新啟動電腦。隨後，透過 grep sdb /proc/partitions 指令，可以驗證核心是否已成功載入新的分割資訊。

磁碟分割類型與用途對照

分割區	容量	類型代碼	類型描述	主要用途
`/dev/sdb1`	5GB	83	Linux	常規檔案系統（如 ext4）
`/dev/sdb2`	5GB	82	Linux swap / Solaris	系統交換空間（Swap）
`/dev/sdb3`	3GB	83	Linux	常規檔案系統（如 ext2）
`/dev/sdb5`	3GB	c	W95 FAT32 (LBA)	跨平台檔案系統（如 VFAT）
`/dev/sdb6`	4GB	8e	Linux LVM	邏輯磁碟管理系統的物理卷準備

此圖示展示了磁碟分割的基本操作流程，從定義分割區的範圍，到指定其檔案系統類型，最終將變更寫入磁碟並確保系統核心能夠辨識。

看圖說話：

此圖示以流程圖的形式，直觀地呈現了在 Linux 環境下，使用指令工具進行磁碟分割的關鍵步驟。首先，使用者透過 t 指令選擇目標分割區，接著輸入代表特定檔案系統類型的十六進位代碼。系統會回饋該分割區的類型已更新的訊息。此過程可重複進行，以設定多個分割區的不同類型。完成所有類型設定後，p 指令用於預覽當前的分割表配置，確保所有變更符合預期。最後，w 指令將修改寫入磁碟，並提示使用者在下次重啟後生效。此流程是建立彈性儲存架構的第一步，為後續的檔案系統格式化或邏輯磁碟管理奠定基礎。

檔案系統的建構與邏輯磁碟管理的引入

在完成磁碟分割並指定了各個分割區的類型後，下一步便是為這些分割區建立實際可用的檔案系統，或是將其準備好供更進階的儲存管理技術使用。

對於 /dev/sdb1，若要將其建構成一個標準的 Linux ext4 檔案系統，我們需執行 mkfs -t ext4 /dev/sdb1 指令。ext4 檔案系統因其穩定性、效能與對大檔案的支援，成為現代 Linux 系統的預設選擇。

對於 /dev/sdb2，先前已將其類型設定為交換空間。要啟用此交換空間，執行 mkswap /dev/sdb2 指令即可。

對於 /dev/sdb3，若要建立一個 ext2 檔案系統，直接執行 mkfs /dev/sdb3 即可，因為 ext2 是 mkfs 命令的預設檔案系統類型。

而 /dev/sdb5，先前被設定為 FAT32 格式。要將其建構成 VFAT 檔案系統，執行 mkfs -t vfat /dev/sdb5 指令。

至於 /dev/sdb6，其類型被設定為 Linux LVM。要將此分割區作為邏輯磁碟管理系統的基礎，必須先將其初始化為一個物理卷（Physical Volume），這透過 pvcreate /dev/sdb6 指令完成。

完成上述步驟後，這些分割區便已準備就緒，可以被掛載（mount）為檔案系統，作為交換空間使用，或納入 LVM 的管理之下。

邏輯磁碟管理（LVM）的必要性與優勢

傳統的磁碟分割方式，在面對儲存空間不足時，往往需要複雜且耗時的資料遷移與系統重啟過程，這不僅影響服務可用性，也降低了營運效率。邏輯磁碟管理（LVM）技術的出現，為了解決這些挑戰提供了極大的彈性與效率。

LVM 的核心概念是將物理磁碟分割區（即我們剛剛創建的物理卷）匯集到一個或多個儲存池中，這些儲存池被稱為「磁碟區群組」（Volume Groups）。隨後，系統可以從這些磁碟區群組中動態地分配空間，創建出「邏輯磁碟區」（Logical Volumes）。這種架構帶來了以下關鍵能力：

彈性空間分配：邏輯磁碟區的大小可以根據實際需求進行調整，包括擴展或縮減，而無需重新分割物理磁碟。
快照功能：LVM 支援創建檔案系統的快照，這對於備份、測試或回滾操作至關重要，能夠在不影響線上服務的情況下進行。
跨裝置整合：可以將多個物理磁碟或分割區組合成一個單一的磁碟區群組，進而創建出橫跨多個實體裝置的邏輯磁碟區，突破單一裝置容量的限制。
線上調整：許多 LVM 操作，如擴展邏輯磁碟區，可以在系統運行時進行，最大程度地減少停機時間。

透過 LVM，儲存管理不再是僵化的分割，而是變得如同經營一個靈活的資金池，可以隨時按需調度資源，極大地提升了系統的可維護性與擴展性。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

rectangle "實體磁碟 (/dev/sdb)" as PhysicalDisk {
  rectangle "/dev/sdb1 (ext4)" as Partition1
  rectangle "/dev/sdb2 (Swap)" as Partition2
  rectangle "/dev/sdb3 (ext2)" as Partition3
  rectangle "/dev/sdb5 (VFAT)" as Partition5
  rectangle "/dev/sdb6 (LVM PV)" as Partition6
}

rectangle "磁碟區群組 (Volume Group)" as VG {
  Partition6 --> VG : 納入
}

rectangle "邏輯磁碟區 (Logical Volume)" as LV
VG --> LV : 分配空間

rectangle "掛載點 (Mount Point)" as MountPoint
LV --> MountPoint : 映射

Partition1 --> MountPoint : 映射
Partition2 --> MountPoint : 映射 (Swap)
Partition3 --> MountPoint : 映射
Partition5 --> MountPoint : 映射

note right of Partition6
  初始化為
  物理卷 (PV)
end note

note right of VG
  匯集物理卷
  的儲存空間
end note

note right of LV
  從 VG 動態
  分配的儲存
end note

@enduml

看圖說話：

此圖示描繪了 Linux 儲存架構中的邏輯磁碟管理（LVM）概念。最底層是實體磁碟，如 /dev/sdb，它被劃分為多個分割區。其中，部分分割區（如 /dev/sdb1, /dev/sdb3, /dev/sdb5）被格式化為不同的檔案系統，並可直接掛載到系統的掛載點。另一個分割區 /dev/sdb2 被配置為系統交換空間。關鍵在於 /dev/sdb6，它被初始化為 LVM 的物理卷（PV）。多個物理卷可以匯集起來，形成一個或多個磁碟區群組（VG）。系統接著可以從這些磁碟區群組中，彈性地分配空間來創建邏輯磁碟區（LV）。這些邏輯磁碟區可以被進一步格式化並掛載到系統的掛載點，提供了比傳統分割更靈活的儲存管理能力，尤其是在需要動態調整空間大小或進行快照操作時。

綜合評估後，從傳統的固定磁碟分割到導入邏輯磁碟管理（LVM），不僅是技術操作的演進，更是一場深刻的系統架構思維典範轉移。靜態分割雖然直觀且易於初始設定，但在面對動態增長的業務需求時，其僵化的空間限制往往成為系統擴展性的關鍵瓶頸，並在無形中累積了高昂的維運成本與架構債。

深入剖析可以發現，LVM 的核心價值在於引入了一個關鍵的「抽象層」，將底層的物理儲存轉化為可靈活調度的策略性資產。這使得儲存空間的擴展、縮減乃至快照備份，皆能從容應對，大幅提升了系統的維運韌性與生命週期內的管理效率。相較於傳統分割一次性、不可逆的規劃，LVM 提供的是一種持續演進、隨需應變的治理能力，這對於追求高可用性與長期發展的關鍵應用至關重要。

展望未來，這種將實體資源抽象化、池化再分配的管理哲學，正是當前雲端運算與容器化技術的核心。無論是公有雲的彈性區塊儲存（EBS），還是 Kubernetes 中的儲存類別（StorageClass），其背後都蘊含著與 LVM 相似的資源調度邏輯。因此，掌握 LVM 不僅是解決當下的儲存挑戰，更是為駕馭未來更複雜的雲原生架構奠定基礎。

玄貓認為，對於任何預期會持續發展的資訊系統而言，將 LVM 納為標準儲存架構，已非選項，而是確保長期競爭力的策略性佈局。高階技術管理者應優先將此思維導入團隊，從而建構出更具彈性與前瞻性的數位基礎設施。