檔案系統 on KnightLi的博客

Btrfs Scrub 使用指南：資料校驗、自動修復與定期巡檢

Sat, 09 May 2026 07:11:01 +0800

Btrfs scrub 是 Btrfs 日常維護裡最重要、也最容易被誤解的功能之一。它不是傳統意義上的 fsck，而是一種線上校驗流程：讀取檔案系統中的資料和 metadata，驗證校驗和、superblock、metadata block header 以及磁碟讀取錯誤，並在有可靠副本時嘗試修復損壞。

如果你的 Btrfs 用在 NAS、家用伺服器、備份碟或多碟陣列上，scrub 應該成為定期巡檢的一部分。它的價值不是「等出事再修」，而是在磁碟還能讀、陣列還有好副本的時候，盡早發現靜默損壞。

scrub 到底檢查什麼

根據 Btrfs 官方文件，scrub 會遍歷檔案系統資料和 metadata，主要檢查：

資料區塊校驗和錯誤。
基礎 super block 錯誤。
基礎 metadata block header 錯誤。
磁碟讀取錯誤。

在使用複製型 block group profile 的檔案系統上，例如 RAID1，讀寫掛載下的 scrub 可以自動修復部分損壞。修復方式不是「憑空恢復」，而是從另一個已驗證正確的副本複製好資料回來。

這點很關鍵：scrub 的修復能力依賴「存在可用的好副本」。如果單碟上只有一份資料，scrub 可以發現校驗錯誤，但通常無法自行恢復原始內容。

常用命令

對掛載點啟動 scrub：

`1`	`sudo btrfs scrub start /`

以前台方式執行，適合手動觀察結果：

`1`	`sudo btrfs scrub start -B /`

查看狀態：

`1`	`sudo btrfs scrub status /`

取消正在執行的 scrub：

`1`	`sudo btrfs scrub cancel /`

恢復被中斷的 scrub：

`1`	`sudo btrfs scrub resume /`

如果指定的是 Btrfs 掛載路徑，Btrfs 會平行 scrub 該檔案系統裡的所有裝置。如果指定的是某個裝置，則只 scrub 該裝置；但當指定裝置上的副本讀取或校驗失敗時，Btrfs 仍會嘗試從其他裝置讀取好副本。

scrub 不是 fsck

這是最容易踩坑的地方。scrub 不是 btrfs check，也不是傳統意義上的檔案系統檢查器。

scrub 能做的是：

利用校驗和發現資料或 metadata 損壞。
在有其他可靠副本時自動修復。
發現磁碟讀取錯誤和部分基礎結構錯誤。

scrub 不能做的是：

重建沒有好副本的資料。
替代離線檔案系統檢查。
修復所有複雜的樹結構損壞。
保證應用層檔案內容一定正確。

如果檔案系統結構已經嚴重損壞，通常需要在專家指導下使用 btrfs check 等工具。不要把 scrub 當成「萬能修復命令」。

NOCOW 檔案的風險

Btrfs 官方文件特別提醒：對檔案設定 NOCOW 屬性，也就是常見的 chattr +C，目前實作中會隱式啟用 NODATASUM。這意味著這些檔案的資料本身沒有校驗和。

scrub 仍然可以校驗和修復這些檔案的 metadata，但不能校驗檔案資料內容。問題在多副本場景裡尤其明顯：如果某個 NOCOW 檔案的一個副本壞了，Btrfs 沒有資料校驗和判斷哪個副本是好的，就可能把壞內容返回給使用者空間工具。

需要特別注意的是，一些軟體會預設使用 +C 來提升效能。例如 systemd journal 和部分 libvirt 儲存池場景可能會設定 NOCOW。對於虛擬機映像、資料庫、日誌目錄，這種做法有效能理由，但也意味著你不能期待 scrub 像保護普通 COW 檔案那樣保護它們的資料內容。

唯讀 scrub 也可能寫入

另一個反直覺點是：在讀寫掛載的檔案系統上執行 read-only scrub，仍然可能導致一些寫入。

官方文件說明，這是為了避免 block group 標記唯讀和寫回 block group items 之間的競態。換句話說，如果你希望 scrub 過程中完全沒有寫入，就需要在唯讀掛載的檔案系統上執行唯讀 scrub，而不是在讀寫掛載上加一個唯讀 scrub 選項就完事。

對普通使用者來說，這意味著：

日常線上 scrub 可以在讀寫掛載上執行。
如果你在做取證、故障分析或極度保守的唯讀檢查，要先明確掛載狀態。
不要把 read-only scrub 誤解成絕對零寫入。

中斷與恢復

新內核中，scrub 可能被多種事件中斷，例如系統掛起/休眠、檔案系統凍結、cgroup freezing、pending signals 等。被中斷後，正在執行的 scrub 會取消，但可以透過 btrfs scrub resume 從保存的位置繼續。

scrub 狀態會記錄在：

`1`	`/var/lib/btrfs/`

檔案名通常類似：

1
2

scrub.status.UUID
scrub.progress.UUID

狀態檔案會定期更新。恢復 scrub 時，會從最後保存的位置繼續，而不是完全從頭再來。

建議多久跑一次

官方建議的週期是每月一次，實際可以根據資料重要性和磁碟狀態調整。

比較常見的安排是：

家用 NAS：每月一次。
備份碟：每次長期接入後或每月一次。
重要多碟陣列：每月一次，必要時更頻繁。
新碟遷移或懷疑壞碟：遷移後立即跑一次。

scrub 在空閒檔案系統上的裝置頻寬利用率可能接近 80%，所以不要在業務高峰期跑。對機械碟陣列，scrub 期間延遲可能明顯升高；對 SSD，也會增加讀放大和後台壓力。

限制 scrub 頻寬

過去可以用 ionice 嘗試降低 scrub 對前台 I/O 的影響，但官方文件提醒，並不是所有 I/O 調度器都支援這種方式。CFQ 已經不再是主流；BFQ 支援相關優先級，但使用前應先理解其行為。對 mq-deadline 等常見調度器，更推薦使用 cgroup2 I/O controller 或 Btrfs 自帶的限速介面。

使用 systemd 限制讀取頻寬的例子：

`1`	`sudo systemd-run -p "IOReadBandwidthMax=/dev/sdx 10M" btrfs scrub start -B /`

Linux 5.14 以後，可以透過 Btrfs 專用 sysfs 介面設定每裝置 scrub 限速：

`1`	`echo 100m \| sudo tee /sys/fs/btrfs/FSID/devinfo/DEVID/scrub_speed_max`

查看目前限制：

`1`	`sudo btrfs scrub limit /`

注意這個設定不是永久的，檔案系統卸載後會失效。實際路徑裡的 FSID 和 DEVID 要按你的系統替換，可以先查看：

1
2

sudo btrfs filesystem show /
ls /sys/fs/btrfs/

實用維護流程

一個比較穩妥的 Btrfs 巡檢流程可以是：

sudo btrfs scrub start -B /
sudo btrfs scrub status /
sudo btrfs device stats /
dmesg -T | grep -Ei "btrfs|checksum|i/o error|read error"

如果 scrub 報告有 corrected errors，說明已經從好副本修復過資料，但這不代表可以忽略。你應該繼續檢查磁碟 SMART、線材、電源、控制器和 Btrfs device stats。

如果 scrub 報告 uncorrectable errors，說明 Btrfs 找不到可用好副本，必須盡快備份仍能讀取的資料，定位具體檔案或裝置，並根據情況替換硬碟或從備份恢復。

總結

Btrfs scrub 的定位很明確：它是線上資料巡檢和副本修復工具，不是 fsck，也不是備份。

它最適合用在有校驗和、有冗餘副本的 Btrfs 檔案系統上，定期發現靜默損壞並自動從好副本恢復。它不能保護沒有校驗和的 NOCOW 檔案資料，也不能在沒有好副本時憑空恢復損壞內容。

如果你使用 Btrfs 存重要資料，建議每月跑一次 scrub，配合 SMART、device stats、備份和告警一起使用。真正可靠的資料安全，永遠是校驗、冗餘、監控和備份一起工作，而不是只依賴某一個命令。

參考連結：

Btrfs 官方文件：Scrub

詳解 Linux 7.0 和 7.1 的 NTFS 驅動變化

Sat, 02 May 2026 10:46:20 +0800

Linux 7.0 發布後，7.1 開始進入下一輪特性合併窗口。其中一個值得關注的變化，是新的 NTFS 核心驅動。

這裡的「新」不是說 Linux 第一次支援 NTFS，也不是說 ntfs3 被替換。更準確地說，Linux 7.1 合入了一個新的可選核心態 NTFS 讀寫驅動。它基於早年的核心 ntfs 驅動重新整理，並補上更完整的讀寫能力。

先說結論

Linux 上目前主要有三條 NTFS 路線：

方案	位置	讀寫能力	適合場景
`ntfs-3g`	使用者態 FUSE	讀寫	穩定優先，發行版長期預設方案
`ntfs3`	核心態	讀寫	追求更直接的核心整合和效能
新 `ntfs`	核心態	讀寫	Linux 7.1 新增的可選實作

所以這次變化不是強制遷移，而是多了一種選擇。普通使用者短期內繼續跟隨發行版預設策略即可。

7.0 和 7.1 的關係

Linux 7.0 只是核心版本進入 7.x 系列，不代表 NTFS 支援在 7.0 裡突然重寫。真正和 NTFS 相關的新變化，出現在 7.1 的特性合併階段。

NTFS 一直是 Linux 桌面使用者繞不開的檔案系統：雙系統、外接硬碟、U 盤、Windows 資料碟都會用到它。問題在於，NTFS 寫入路徑複雜，一旦驅動有 bug，風險可能直接落到資料上。因此核心社群對 NTFS 驅動會比較謹慎。

`ntfs-3g`、`ntfs3` 和新 `ntfs`

ntfs-3g 是使用者態 FUSE 驅動，長期承擔 Linux 上的 NTFS 讀寫任務。它效能不一定最好，但成熟、相容性好，資料也多。

ntfs3 是 Paragon Software 貢獻的核心態 NTFS 驅動，已經進入 Linux 主線。它路徑更短，和 VFS 整合更直接，理論效能也更好。但檔案系統驅動對維護品質要求很高，ntfs3 合入後也經歷過維護節奏和程式碼品質方面的討論。

Linux 7.1 新增的 ntfs 驅動，則由 Namjae Jeon 維護。它不是從零開始，而是把舊核心 ntfs 驅動現代化，補齊讀寫能力，作為另一套可選實作與 ntfs3 並存。

這三者的關係可以簡單理解為：

ntfs-3g：保守、成熟、使用者態。
ntfs3：主線已有的核心態方案。
新 ntfs：7.1 新增的核心態方案，還需要觀察穩定性。

應該怎麼選

日常使用不用急著切換。比較穩妥的順序是：

重要資料繼續使用發行版預設方案，通常是 ntfs-3g 或已驗證的 ntfs3。
需要效能時，可以測試 ntfs3。
新 ntfs 驅動先用於測試碟、臨時碟或可恢復資料。
重要 NTFS 分區寫入前先備份。

如果要手動使用 ntfs3，常見掛載方式是：

`1`	`sudo mount -t ntfs3 /dev/sdX1 /mnt/ntfs`

如果只是臨時讀取資料，可以唯讀掛載：

`1`	`sudo mount -o ro /dev/sdX1 /mnt/ntfs`

確認目前使用哪個驅動，可以看掛載資訊：

1
2

findmnt -T /mnt/ntfs
mount | grep ntfs

雙系統使用者要注意

NTFS 分區如果來自 Windows 系統碟，寫入前要先確認 Windows 已真正關機。快速啟動和休眠會讓 NTFS 卷保留未完成狀態，Linux 再寫入可能造成一致性問題。

建議檢查這幾項：

關閉 Windows 快速啟動。
確認分區不在 hibernation 狀態。
BitLocker 或其他加密狀態不會阻礙存取。
外接硬碟在 Windows 中已正常退出。

無論使用 ntfs-3g、ntfs3 還是新 ntfs，這些注意事項都一樣。

為什麼需要多個 NTFS 驅動

同一種檔案系統有多個實作，在 Linux 裡並不罕見。舊實作、新實作、廠商實作、社群實作會並存一段時間，直到維護狀態和實際回饋逐漸分出主次。

NTFS 更適合保守處理，原因很簡單：

使用者資料風險高。
相容場景複雜。
不同實作的效能和穩定性取捨不同。
發行版需要時間驗證預設策略。

因此，Linux 7.1 新 ntfs 驅動的意義，不是立刻淘汰 ntfs-3g 或 ntfs3，而是給核心社群多一個可維護的選擇。

小結

Linux 7.1 新增的 ntfs 驅動，是一個可選的核心態 NTFS 讀寫實作。它和 ntfs-3g、ntfs3 並存，不是直接替代誰。

普通使用者可以繼續使用發行版預設方案；需要折騰或測試效能的人，可以關注 ntfs3 和新 ntfs 的後續穩定性。涉及重要資料時，優先備份，再考慮切換驅動。

Linux Kernel 7.0 更新特性整理

Fri, 01 May 2026 14:46:07 +0800

Linux 核心版本號一直不是語意化版本號，主版本號提升更多是維護節奏上的滾動。 Linus Torvalds 在發布郵件中也把 7.0 描述成一次正常發布：最後一週主要是網路、架構、工具、自測和驅動等方向的小修小補。

真正值得關注的是這批增量更新本身。 Linux 7.0 覆蓋了檔案系統、記憶體管理、硬體支援、安全隔離、Rust 支援和驅動清理等多個方向。

檔案系統：XFS、EXT4、NTFS3 都有變化

Linux 7.0 最容易被感知的一類更新在檔案系統。

XFS 引入了自我修復相關能力。配合新的通用檔案系統錯誤回報機制，檔案系統可以把 metadata 損壞和 I/O 錯誤透過更統一的方式傳遞到使用者空間。在合適的系統服務配合下，XFS 可以在檔案系統仍然掛載時自動處理部分修復流程。這並不等於所有磁碟損壞都能無痛修好，但對伺服器和長期執行系統來說，錯誤發現和修復鏈路更完整。

EXT4 繼續改善並行 direct I/O 寫入表現。如果機器上經常有備份、建置、下載、資料庫或日誌任務同時寫盤，這類最佳化會讓並行寫入路徑更穩。它不是那種所有桌面使用者馬上能感知的變化，但對高 I/O 場景有意義。

NTFS3 也獲得了較大的驅動更新，包括 delayed allocation、基於 iomap 的檔案操作，以及大目錄掃描場景下更好的 readahead。如果經常在 Linux 下存取 Windows 分割區或外接 NTFS 磁碟，這類更新更值得留意。

此外，exFAT 改進了多 cluster 順序讀取，部分小 cluster 裝置在順序讀取時會更快。

記憶體與 swap：繼續最佳化記憶體壓力下的表現

Linux 7.0 延續了前幾個版本對 swap 子系統的整理。這次重點之一是改進從 swap 讀回記憶體的路徑，尤其是多個行程共享同一批被換出的記憶體頁時，吞吐會更好。

對桌面使用者來說，這不一定會變成明顯的「系統突然更快」。但在記憶體緊張、容器密集、Redis 這類服務啟用持久化，或 zram 搭配後端磁碟的場景裡，這類變化會減少系統在記憶體壓力下的抖動。

zram 相關路徑也有最佳化。過去某些情況下，核心需要先把 zram 頁面解壓再寫入後端裝置；新的路徑可以直接寫入壓縮資料，減少不必要的處理。

CPU 與效能：Intel TSX auto、執行緒和檔案操作更快

Linux 7.0 對 Intel TSX 的預設策略做了調整。過去因為安全問題，TSX 在不少處理器上預設關閉。現在核心採用更細的 auto 策略：受影響的 CPU 繼續關閉，不受影響或適合啟用的 CPU 可以自動打開。

這對部分多執行緒工作負載會有幫助，尤其是依賴事務同步擴展的應用。不過它不是通用加速開關，實際收益仍取決於 CPU 型號和應用是否使用相關能力。

另外，Linux 7.0 還包含 PID 分配、執行緒建立/銷毀、檔案 open/close 等路徑的最佳化。這些最佳化通常不會單獨成為宣傳點，但會累積成系統回應和高並行服務上的細微收益。

硬體支援：新平台預備和現有裝置改善

Linux 7.0 繼續做大量硬體啟用工作。這類更新通常分成兩類：一類是還沒大規模上市的新平台預備，另一類是已經在使用者手上的裝置改善。

新平台方面，Linux 7.0 包含更多 Intel Nova Lake、Intel Crescent Island、AMD 新圖形 IP、AMD Zen 6 相關準備工作。這類改動對普通使用者不一定馬上有用，但它決定了新硬體上市後能否更快獲得主線核心支援。

ARM64 和單板機方向，Rockchip RK3588/RK3576 的 H.264/H.265 硬體影片解碼進入主線支援範圍。這意味著 Orange Pi 5、Radxa ROCK 5 等裝置不再完全依賴廠商 BSP 核心才能獲得硬解體驗。

筆電和外設方向也有不少細節更新：

ASUS WMI 改善 ROG、TUF 機型的背光、鍵盤燈和風扇快捷鍵支援；
HP WMI 增加部分 Victus 機型的手動風扇控制和音訊指示燈修正；
Lenovo WMI 為 Legion 裝置暴露更多 HWMON 監控資訊；
Intel Xe 圖形驅動暴露更多溫度感測器；
Intel Arc B 系列獨顯可以進入更深的 PCIe 省電狀態；
Rock Band 4 藍牙吉他和 Logitech K980 藍牙鍵盤獲得更好的核心支援。

這些變化單看都不大，但對筆電、遊戲裝置、開發板和外設使用者來說，主線核心支援越完整，後續發行版維護越省心。

安全與隔離：io_uring 可以做 BPF 過濾

Linux 7.0 給 io_uring 增加了 BPF 過濾能力。這對容器、沙箱和高安全要求環境比較重要。

過去一些管理員為了降低攻擊面，會直接停用 io_uring。現在透過 BPF 過濾，可以更細地限制允許的操作，而不是只能在「全開」和「全關」之間選擇。

這不會讓 io_uring 的安全風險自動消失，但給系統管理員和執行時框架提供了更可控的隔離手段。

Rust 支援不再只是實驗標籤

Linux 7.0 中，Rust for Linux 的狀態進一步穩定。這不意味著核心會大規模改寫成 Rust，也不意味著 C 會被替代。

更準確地說，Rust 在核心裡的基礎設施已經進入更正式的階段。後續新驅動、新子系統或部分安全敏感程式碼，可以在合適場景下選擇 Rust。這是一條漸進路線：先把介面、建置、文件和維護流程打穩，再讓具體程式碼慢慢增加。

清理舊功能：laptop_mode 被移除

Linux 7.0 移除了 laptop_mode。這是一個歷史很久的省電功能，主要面向機械硬碟時代的筆電，透過減少磁碟喚醒來節省電量。

現在筆電主流已經是 SSD，核心裡的記憶體回收、區塊裝置和檔案系統路徑也發生了很多變化。繼續保留這種老機制會增加維護成本，而且測試覆蓋並不理想。移除它可以減少舊程式碼對現代路徑的干擾。

AI 相關按鍵：面向新一代鍵盤互動

Linux 7.0 增加了幾個新的 HID keycode，用於上下文 AI 互動場景，例如對選中內容執行動作、插入上下文生成內容、發起上下文查詢等。

這並不是核心內建 AI 功能。它更像是給未來筆電鍵盤和外設留好輸入事件定義，讓桌面環境、應用或廠商工具可以識別這些按鍵。實際能做什麼，仍取決於發行版、桌面環境和應用層整合。

是否應該馬上升級

如果你使用滾動發行版，Linux 7.0 很可能會自然進入系統更新。如果你使用 Ubuntu 26.04 LTS 這類新發行版，7.0 也會作為預設或主要核心版本出現。

但如果你的機器是生產環境、NAS、虛擬化宿主機，或依賴閉源驅動和專有核心模組，不建議只因為版本號變成 7.0 就立刻手動升級。更穩妥的做法是：

等發行版提供正式核心套件；
查看顯示卡、網卡、ZFS、VirtualBox、VMware、DKMS 模組相容性；
在測試機或快照環境裡先驗證；
關注 7.0.x 小版本修復情況。

截至 kernel.org v7.x 目錄，7.0.1、7.0.2、7.0.3 已經陸續發布。如果要手動建置或測試，優先選擇最新的 7.0.x 穩定小版本，而不是只盯著最初的 7.0 tarball。

小結

Linux Kernel 7.0 不是一次「因為大版本號而重寫一切」的發布。它更像是一次覆蓋面很廣的常規核心更新：檔案系統更可靠，swap 和 I/O 路徑繼續最佳化，新硬體支援繼續前移，Rust、io_uring 隔離和 HID 輸入定義也在補齊長期演進所需的基礎設施。

對普通桌面使用者來說，最實際的變化可能來自硬體支援、圖形驅動、省電和檔案系統修復。對伺服器和開發者來說，XFS 錯誤回報、自我修復、io_uring BPF 過濾、swap 最佳化和新平台支援更值得關注。

參考來源：