Log for Ubuntu 台灣社群
案例分析：救回一個受損的 12 TB 多裝置 Btrfs 儲存池 （★ 77 分）
這份案例紀錄描述一個 12 TB、由 3 顆磁碟組成的 Btrfs（Linux 的寫入時複製檔案系統）儲存池，因一次硬斷電而在提交期間受損。該儲存池採用資料 `single`、中介資料 `DUP`，磁碟則是 DM-SMR（device-managed shingled magnetic recording，裝置管理型疊瓦式磁記錄）型號。事故後，extent tree（記錄資料區塊配置的樹）與 free space tree（記錄可用空間的樹）同時異常，原生修復流程無法排除問題；更糟的是，執行 `btrfs check --repair` 後進入超過 4.6 萬次提交的無限迴圈，沒有實質進展，還把 `backup_roots` 這組僅保留最近四次提交狀態的槽位輪替掉，失去回到斷電前狀態的機會。
作者最後以 14 個自行撰寫的 C 工具，直接運用 `btrfs-progs` 內部 API，才把儲存池救回可用狀態；4.59 TB 的資料中，最終損失約 7.2 MB，約占 0.00016%。這份報告不是抱怨文，而是把復原過程整理成可供上游參考的案例分析，並提出九個優先改善方向：例如替 `btrfs check --repair` 加入進度偵測以避免空轉、提供能從預掃描參照清單重建 extent tree 的救援子命令、清理孤兒 inode（索引節點）時加入乾跑模式與安全檢查、修正區塊群組使用量統計，以及更清楚說明 `backup_roots[0..3]` 其實只是四次提交滑動視窗，而非歷史備份。
作者也公開了完整工具組與一個單行修補程式，採 GPL-2.0（GNU 通用公共授權第 2 版）釋出，預設都是唯讀掃描，只有明確加上 `--write` 才會真正改寫磁碟。其重點不在直接要求上游收進這 14 個工具，而是展示哪些缺口若能由 `btrfs-progs` 原生補上，未來類似災情就不必仰賴臨時開發的外部工具。作者並表示願意提供更多工作紀錄與測試協助，希望把這次經驗轉成更可操作的救援能力與文件改善。
留言區的主軸則是對 Btrfs 在多裝置情境下的穩定度抱持強烈保留。有人肯定作者的工程能力，但認為一次硬斷電竟要靠 14 個客製工具才能救回資料，本身就說明風險過高；也有不少人轉而推薦 ZFS（具完整性校驗與儲存池管理的檔案系統）、CephFS（Ceph 分散式檔案系統），或是 ext4 / XFS 搭配 LVM（邏輯磁碟管理）與 dm-integrity。另一派則指出，在 Linux 官方核心內、又要多裝置與資料校驗時，Btrfs 仍是少數選項，因此更應把設定限制講清楚，例如避免 Btrfs 的 RAID 5/6，並把中介資料從 `DUP` 改成 `raid1` 或 `raid1c3`。討論中也有人質疑，這份案例尚未精準鎖定最初的觸發 bug，只是完整揭露了哪些地方讓復原變得更困難；另一些人則懷疑這批工具可能有大型語言模型（LLM, Large Language Model）協助撰寫。不過整體共識相當一致：無論根因是單一 bug、設計邊界或操作設定，只要正常硬斷電就可能把儲存池推到原生工具難以挽回的狀態，這個訊號對正式環境使用者已經足夠嚴重。
👥 34 則討論、評論 💬
https://news.ycombinator.com/item?id=47656303
這份案例紀錄描述一個 12 TB、由 3 顆磁碟組成的 Btrfs（Linux 的寫入時複製檔案系統）儲存池，因一次硬斷電而在提交期間受損。該儲存池採用資料 `single`、中介資料 `DUP`，磁碟則是 DM-SMR（device-managed shingled magnetic recording，裝置管理型疊瓦式磁記錄）型號。事故後，extent tree（記錄資料區塊配置的樹）與 free space tree（記錄可用空間的樹）同時異常，原生修復流程無法排除問題；更糟的是，執行 `btrfs check --repair` 後進入超過 4.6 萬次提交的無限迴圈，沒有實質進展，還把 `backup_roots` 這組僅保留最近四次提交狀態的槽位輪替掉，失去回到斷電前狀態的機會。
作者最後以 14 個自行撰寫的 C 工具，直接運用 `btrfs-progs` 內部 API，才把儲存池救回可用狀態；4.59 TB 的資料中，最終損失約 7.2 MB，約占 0.00016%。這份報告不是抱怨文，而是把復原過程整理成可供上游參考的案例分析，並提出九個優先改善方向：例如替 `btrfs check --repair` 加入進度偵測以避免空轉、提供能從預掃描參照清單重建 extent tree 的救援子命令、清理孤兒 inode（索引節點）時加入乾跑模式與安全檢查、修正區塊群組使用量統計，以及更清楚說明 `backup_roots[0..3]` 其實只是四次提交滑動視窗，而非歷史備份。
作者也公開了完整工具組與一個單行修補程式，採 GPL-2.0（GNU 通用公共授權第 2 版）釋出，預設都是唯讀掃描，只有明確加上 `--write` 才會真正改寫磁碟。其重點不在直接要求上游收進這 14 個工具，而是展示哪些缺口若能由 `btrfs-progs` 原生補上，未來類似災情就不必仰賴臨時開發的外部工具。作者並表示願意提供更多工作紀錄與測試協助，希望把這次經驗轉成更可操作的救援能力與文件改善。
留言區的主軸則是對 Btrfs 在多裝置情境下的穩定度抱持強烈保留。有人肯定作者的工程能力，但認為一次硬斷電竟要靠 14 個客製工具才能救回資料，本身就說明風險過高；也有不少人轉而推薦 ZFS（具完整性校驗與儲存池管理的檔案系統）、CephFS（Ceph 分散式檔案系統），或是 ext4 / XFS 搭配 LVM（邏輯磁碟管理）與 dm-integrity。另一派則指出，在 Linux 官方核心內、又要多裝置與資料校驗時，Btrfs 仍是少數選項，因此更應把設定限制講清楚，例如避免 Btrfs 的 RAID 5/6，並把中介資料從 `DUP` 改成 `raid1` 或 `raid1c3`。討論中也有人質疑，這份案例尚未精準鎖定最初的觸發 bug，只是完整揭露了哪些地方讓復原變得更困難；另一些人則懷疑這批工具可能有大型語言模型（LLM, Large Language Model）協助撰寫。不過整體共識相當一致：無論根因是單一 bug、設計邊界或操作設定，只要正常硬斷電就可能把儲存池推到原生工具難以挽回的狀態，這個訊號對正式環境使用者已經足夠嚴重。
👥 34 則討論、評論 💬
https://news.ycombinator.com/item?id=47656303
Linux 準備移除對 i486 CPU 的支援
Linux 準備移除對 i486 CPU 的支援，名為「x86/cpu: Remove M486/M486SX/ELAN support」的修補程式預計將合併到 Linux 7.1 中。英特爾是在 1989 年 4 月推出 25 MHz i486 CPU，33 MHz i486 則於 1990 年 5 月發表，50 MHz 版本於 1991 年 6 月推出。英特爾對 i486 的生產一路持續到 2007 年。i486 的後繼產品是 1993 年推出的 Pentium（奔騰）CPU。i486 也是 AMD 最後一款英特爾處理器相容產品。Linux 核心過去幾年已經多次考慮移除對 i486 的支援。Linux 創作者 Linus Torvalds 最近再次表示，不應該再把心力浪費在支援 i486 上。
https://www.phoronix.com/news/Linux-7.1-Phasing-Out-i486
https://www.phoronix.com/news/Linux-7.1-Phasing-Out-i486
Linux 準備移除對 i486 CPU 的支援，名為「x86/cpu: Remove M486/M486SX/ELAN support」的修補程式預計將合併到 Linux 7.1 中。英特爾是在 1989 年 4 月推出 25 MHz i486 CPU，33 MHz i486 則於 1990 年 5 月發表，50 MHz 版本於 1991 年 6 月推出。英特爾對 i486 的生產一路持續到 2007 年。i486 的後繼產品是 1993 年推出的 Pentium（奔騰）CPU。i486 也是 AMD 最後一款英特爾處理器相容產品。Linux 核心過去幾年已經多次考慮移除對 i486 的支援。Linux 創作者 Linus Torvalds 最近再次表示，不應該再把心力浪費在支援 i486 上。
https://www.phoronix.com/news/Linux-7.1-Phasing-Out-i486
https://www.phoronix.com/news/Linux-7.1-Phasing-Out-i486