為什麼新買的 8TB 雙硬碟 NAS,可用空間少了約 225GB?–ASUSTOR ADM 案例
為什麼新買的 8TB 雙硬碟 NAS,可用空間少了約 225GB?–ASUSTOR ADM 案例

很多企業或家庭使用者第一次建立 NAS 時,常會遇到一個疑問: 「我買的是兩顆 8TB 硬碟,組 RAID 1 之後,為什麼可用容量不是接近 8TB?」 這篇文章整合了工程師從 ADM 介面、Btrfs 底層 extent tree 一路追蹤、最後致電 ASUSTOR 原廠客服確認的完整調查結果。結論先說: 這 225GB 不是 NAS 偷吃掉的容量,也不是系統故障,而是 ASUSTOR 在 Btrfs 檔案系統初始化時,主動配置的 filesystem safety reservation——一道防止容量滿載後系統失去自救能力的安全護欄。 一、RAID 1:兩顆 8TB,可用容量只有一顆 RAID 1 的運作方式是「鏡像複製」——兩顆硬碟的內容完全相同,其中一顆是另一顆的即時備份: 硬碟 A(8TB) 資料 100% 寫入 ⇄ 硬碟 B(8TB) 同步複製,內容完全相同 因此容量計算是 8TB(可用)+ 8TB(保護)= 8TB 可存資料,另一顆提供的是「硬碟壞掉後資料仍然完整」的能力。這正是企業最常選用 RAID 1 的原因。 二、硬碟標示... » read more

快速掌握 不迷路 ! (From Synology to ASUSTOR)
快速掌握 不迷路 ! (From Synology to ASUSTOR)

這張表的起點,是一個很具體的場景:客戶原本用 Synology,現在要導入 ASUSTOR。不是因為 Synology 不好,而是因為這次的需求、預算、或硬體規格,ASUSTOR 是更合適的選擇。 問題在於,熟悉 DSM 的人,第一次面對 ADM,通常不是「不會用」,而是「不知道那個功能叫什麼」。Hyper Backup 在哪裡?QuickConnect 的對應是什麼?Container Manager 換了什麼名字?這些問題不難,但每個問題都要搜尋一次,累積起來就是學習摩擦。 這份對照表的目的,就是消除這個摩擦。把你在 DSM 已經熟悉的功能名稱,直接映射到 ADM 的對應位置。每一項都附上 ASUSTOR College 課程編號或官方功能頁連結,可以當場驗證,不用相信我說的。 表格裡標「缺席」的地方,我沒有試圖找替代方案來補洞。那些缺口是真實存在的差距,尤其是 Active Backup 生態系——這是在評估是否導入 ASUSTOR 之前,最需要誠實面對的問題。如果你的環境高度依賴 Active Backup for Business 或 Microsoft 365 備份,這份表格應該幫你更快做出判斷,而不是說服你換機。 標「類似」的地方,表示功能存在、但操作邏輯或整合深度有差異,需要一點時間適應。標「等效」的地方,換個名字、找到對應選單,基本上就能繼續工作。 這不是一份「ASUSTOR 比較好」的文件。這是一份「如果你已經決定用 ASUSTOR,這樣對照會快一點」的工具。剩下的問題——備份架構怎麼規劃、Container 服務怎麼遷移、異地備援怎麼設計——那是工程服務的範疇,不是一張表能解決的事。 先理解兩個品牌的設計方向 Synology 軟體生態優先,NAS 是企業服務平台。套件深度整合 DSM,換機成本高但體驗完整。 ASUSTOR 硬體彈性與應用自由度優先,NAS 是多功能 Linux 主機。開放彈性高,對熟悉 Linux / Docker... » read more

同齡不同命:PDM 伺服器硬碟故障全記錄
同齡不同命:PDM 伺服器硬碟故障全記錄

工程師思路系列 · 事出必有因 同齡不同命:PDM 伺服器硬碟故障全記錄 兩顆同批硬碟、截然不同的 S.M.A.R.T. 數據,說明了一件事—— 客戶的 PDM 主機頻繁出現 BSOD,三趟現場、兩顆硬碟更換、一次與故障碟搶時間的緊急救援——這篇文章完整記錄過程與教訓,以及這個案例如何成為我們開發硬碟分析工具的直接動機。 伺服器硬碟配置 磁碟 型號 用途 最終狀態 Disk 1 Seagate Exos E7B 2TB C:(Windows Server 2016)+ E:(備份區) 健康,無明顯瑕疵磁區 Disk 2 Seagate Exos E7B 2TB Oracle 資料庫 + PTC Windchill / Creo 設計檔案 瑕疵磁區數以萬計,已嚴重劣化 兩顆硬碟同型號、同時間採購上線,帳面上應該「狀況差不多」。實際展開 S.M.A.R.T. 數據後,結果令人震驚——兩顆同齡的硬碟,健康落差大到像是相差了好幾個世代。 「同齡不同命」——Workload Rate Limit 沒說的那件事 廠商的 Workload Rate Limit(年工作量上限)衡量的是「搬運了多少資料」,而不是「磁頭來回了幾次」。 Disk... » read more

工程師思路系列・事出必有因: 當 SMART 亮紅燈,工程師看到的不只是壞掉的硬碟
工程師思路系列・事出必有因: 當 SMART 亮紅燈,工程師看到的不只是壞掉的硬碟

工程師思路系列・事出必有因 一顆硬碟的遺言 當 SMART 亮紅燈,工程師看到的不只是壞掉的硬碟 Mr. τ | 風雲網通系統有限公司 · 2026 年 7 月 · 閱讀時間約 8 分鐘 接到電話的時候,已經是下午了。 對方是台中一家自動化機械設計公司的負責人,語氣有些急:「工程師說伺服器怪怪的,你可以過來看一下嗎?」 出門前,我把診斷隨身碟、備援硬碟、萬用電表、起子、網路線一件件放進工具箱。每次遇到這種電話,我都不知道今晚幾點回公司。路上順手買了一罐提神飲料。 到了現場,把診斷隨身碟插進前面板的 USB。沒有反應。換到後面板,才順利開機進入診斷環境。 大多數人看到的是:USB 壞了。 我看到的是:這台機器已經老化到開始出現第二層症狀了。 答案後來出來了——車程不計,現場停留時間:5 小時 13 分鐘。 SMART 亮了什麼燈 執行硬碟健康診斷後,畫面上出現了這一行: SMART overall-health self-assessment test result: FAILED! Drive failure expected in less than 24 hours. SAVE ALL DATA. 不是警告,是宣判。預計 24 小時內故障,請立即備份所有資料。 幾個關鍵數字: 22,984 重新分配磁區數(壞軌數,正常應為 0)... » read more

從一個念頭,到一套能力 : 一段工程演進,看見企業隱性智慧如何變成資產
從一個念頭,到一套能力 : 一段工程演進,看見企業隱性智慧如何變成資產

PCPiLOT 工程師思路系列 從一個念頭,到一套能力 一段工程演進,看見企業隱性智慧如何變成資產 7月6日,星期日傍晚六點。 我原本只是想解決一個採購效率問題。 沒有規劃十六個版本。沒有想過要做成什麼平台。甚至沒有想過,這件事最後會和企業 AI 轉型產生任何連結。 我只是覺得:「這件事如果能自動化,應該會更好。」 就這樣開始了。 十天後,我回頭看,發現自己走過的這條路,其實不只是寫了一個工具。 而是驗證了一件事: 一個人累積多年的判斷經驗,可以被整理、被保存、被傳承——變成任何人都能使用的能力。 第一天:先讓資料進來 程式第一版做的事情很簡單。 跑完,螢幕印出幾十個型號的價格和現貨數量,整齊排列。 就這樣。 但那個當下,看著原本需要手動搜尋幾十次的事情,變成幾秒鐘自動完成——有一種說不清楚的滿足感。 不是因為做了什麼了不起的東西。 而是因為:一個念頭,開始變成真實。 有用。繼續。 幾天後:資料進來了,但還不夠 數字有了,問題來了。 「這顆值不值得買?」 光看價格和筆數,還是不知道。 於是開始加東西:幾個核心、功耗多少瓦、效能評分、有沒有內建顯示晶片。 資料開始變成資訊。但我知道,資訊還不夠——真正需要的,是判斷。 關鍵轉折:把多年的經驗寫進去 這是整個過程中,讓我最有感觸的一步。 有一顆叫 E5-2678 v3 的處理器。規格表上就是幾個數字,看不出任何特別之處。 但我知道它的故事。 這是中國工廠特供的型號,台灣幾乎沒有新品,卻因為大量企業設備汰換而流入二手市場,用一般消費型主機板就能插,效能是同價位產品的好幾倍。這些資訊,不在任何規格表裡,不在任何評測網站上——它只存在於在這個市場裡打滾過的人的記憶中。 我把它寫進去,就七個字: 「中國特供雙路神U。」 看似簡單的七個字,背後是十多年市場經驗壓縮後留下的判斷。 R3 3300X 四核全在同一個運算模組,記憶體延遲極低,實際表現遠超規格,停產後身價反漲。 i5-11400 這一代意外保留了企業級指令集,卻在下一代被取消,是近年最特殊的消費級 CPU。 每一條,都是曾經讓我在某個場合停下來多想一秒的事情。現在,它們全部在工具裡了。 那個夜晚,我盯著螢幕看了很久。不是因為程式有多複雜,而是因為突然意識到: 我一直以為這些判斷只存在我腦子裡,沒想到它們可以被說清楚,被整理出來,被放進一個任何人都能使用的地方。 第一個真正的考驗:報告全部消失 某天早上,打開報告——空白一片。 所有分析、所有資料、所有花了好幾天整理的內容,全部不見了。 那一刻,有一種熟悉的感覺:這種事,做任何事情的過程中都會遇到。 追查之後,發現問題出在一個非常小的地方——一個格式衝突,導致整份報告無法運作。 修好之後,我做了一件比修復本身更重要的事: 把這次的問題、原因、解法,全部寫下來,變成一條守則。... » read more

舊機重灌後的六項必做清單
舊機重灌後的六項必做清單

舊機重灌後的六項必做清單 工程師思路系列 / Mr. τ / 風雲網通系統 📋 這不是教學文,是現場 recovery checklist。拿到機器就照順序跑。 舊電腦重裝系統,很多人第一個念頭是「效能夠不夠用」。但實際跑現場的工程師知道:能不能「正常連線使用」才是第一關。 無論機器多老、系統多精簡,只要目標是「連線作業」,以下六件事要依序確認並處理完畢,才算真正就緒。 ① 上網 → ② 手動校時 → ③ 瀏覽器 → ④ 線上 AI → ⑤ 地端 AI → ⑥ NTP 自動校時 這台機器值得救嗎?快速判斷 在動手之前,先確認手邊的機器是否符合基本門檻。以下三個條件缺一不可: 條件 最低門檻 建議規格 CPU 年份 2011 年後 2013 年後 CPU 世代 Intel Core i 第 2 代(Sandy Bridge) Intel Core... » read more

antiX 26 × fcitx5 × 新酷音:從懷疑人生到徹底搞懂
antiX 26 × fcitx5 × 新酷音:從懷疑人生到徹底搞懂

工程師思路系列 事出必有因 現場實錄 一個 Ctrl+Space,卡了一整晚 antiX 26 × fcitx5 × 新酷音:從懷疑人生到徹底搞懂 我有一台 Acer Aspire 4745G,第一代 i5,4GB RAM,說老不老,說新不新。 它的任務是跟我跑現場——去客戶公司做網路勘查,掃設備、抓封包、出報告。 為了讓這台老筆電跑得動勘查工具,我裝了 antiX 26——一個極度輕量的 Linux 發行版。 裝完之後一切都好,只剩一件事:打不了中文。 「這有什麼難的?」——我當時這樣想 在 Windows 上裝中文輸入法是五分鐘的事。Linux 嘛,查一下文件,跑幾行指令,應該也差不多吧。 結果我低估了這件事。 先裝 fcitx5,按照網路教學一步一步來,裝完重開機——Ctrl+Space,沒反應。 換 fcitx4,一樣。換 ibus,還是一樣。 三套輸入法框架,全部裝了又刪,刪了又裝,環境變數在系統裡留下一堆殘骸互相打架。 讓 Google Search AI 幫我試了四種不同版本,全都失敗。 「是不是 antiX 根本就不支援中文輸入?」 「還是我哪個步驟做錯了?」 「還是這台機器有什麼特殊問題?」 這種時候最消耗心力——不是累,是不知道問題出在哪裡,所以不知道從哪裡修。 換個工具,換個思路 後來我換了方法:不再自己亂試,而是讓 Claude Fable 5 協助我做系統性的診斷。 做法很直接——先寫一支診斷腳本,把系統狀態全部挖出來: 目前裝了哪些輸入法套件、環境變數是什麼值、Display... » read more

Windows 11 更新,有時,不是越新越好
Windows 11 更新,有時,不是越新越好

PCPiLOT FIELD NOTES ✦ 工程現場實錄 Windows 11 更新,有時,不是越新越好 一台 Q470 主機板,三層電源管理的通關紀錄 2026-06 ✦ Mr. τ/風雲網通系統 這篇文章不需要你懂 BIOS 或 Windows 更新機制。 它講的是一件很多人用過幾年的電腦都可能碰到的事:Windows 11 更新越裝越新,機器卻開始出現各種說不清楚的怪現象。睡眠有問題、關機有問題、更新裝不進去——每一個問題看起來都不一樣,但追到最後,指向的是同一個方向。 這是一次真實的維修通關紀錄,也是我交機時跟客戶說的那段話。 起點:以為只是換一顆 SSD 鄰居送來一台 ASUS 商用機(Q470 晶片組),SSD 故障。好消息是還在保固內;壞消息是原廠更換要等兩週。最近 SSD 漲價四到六倍,客戶很冷靜:「等就等。」 於是我用工程部備用的 SATA SSD,做了一次乾淨的 Windows 11 24H2 安裝,讓機器先恢復正常使用。等原廠 SSD 修返,再用系統複製工具把整個環境搬過去。補完主機板驅動,讓 Windows Update 慢慢跑。一切看起來只是例行維修——直到更新開始跑。 ⚠️ 關卡一:DISM 都過了,更新還是卡在 98% KB5095093(選用預覽更新)安裝 → 重新開機 → 更新到 98%... » read more

我們不是花八小時修 bug,是花八小時才發現沒有 bug
我們不是花八小時修 bug,是花八小時才發現沒有 bug

PCPiLOT FIELD NOTES ✦ 數位工具開發實錄 我們不是花八小時修 bug,是花八小時才發現沒有 bug 一次 App 開發的真實除錯紀錄,以及它告訴我們關於 AI 協作、資訊可視化與決策品質的事 2026-06-25 ✦ Mr. τ/風雲網通系統 這篇文章不需要你懂程式。 它講的是一個管理者和決策者都熟悉的問題:當你的團隊花了很長時間解決一個問題,最後發現問題根本不在他們找的地方——那段時間,是怎麼浪費掉的? 我最近第一次開發 Android 手機 App,親身經歷了這件事。過程很痛苦,但教訓很值得分享。 起點:一個真實的市場需求 台灣有超過五百萬慢性病患,他們每天面對一個沒有人幫他們解決的問題: 「站在超商貨架前,拿起一包零食,我能吃嗎?吃多少?今天已經吃太多了嗎?」 我開發的「好口福」App,就是要回答這個問題。使用者輸入身高體重和慢性病狀況,App 掃描食品標示後,給出一個簡單的顏色燈號: 🟢 安心買 🟡 注意量 🔴 地雷區 ⚫ 今日已爆 問題:一個小圖示消失了 App 的主要功能都做好了。最後一個待辦很小:在每個營養素旁邊加一個「ⓘ」圖示,讓使用者點擊後看到健康說明。 程式碼寫好了。系統檢查通過。部署完成。 但手機上,那個圖示完全不見了。 接下來的八小時 我和 AI 協作工具花了將近八小時排查這個問題。每一個假設都被否定: 假設一 程式碼沒有寫對 逐行核查後確認程式碼正確。❌ 不是這個。 假設二 手機作業系統的顯示 bug 查到真實存在的 bug 並修正,還是看不到。❌... » read more

一台印表機故障,如何長出一套診斷工具
一台印表機故障,如何長出一套診斷工具

從一次客戶故障,到一套診斷工具的誕生 工程師思路系列:好心辦壞事 —— 一台印表機故障,如何長出一套診斷工具 有些問題,看起來像設備故障。 有些問題,看起來像驅動程式損壞。 但真正深入追查後才發現, 問題其實來自一個原本出於善意的設計。 這次的個案,就是如此。 問題出現 家中有一台 HP Smart Tank 510 無線印表機。 多台 Windows 11 電腦長期正常使用。 但其中一台電腦,某天開始突然無法列印。 更奇怪的是: 測試頁正常 印表機狀態頁正常 Ping 正常 印表機顯示 Online 唯獨 PDF 與 Word 文件送出後, 印表機只動一下就停住。 彷彿設備正常, 卻又無法真正工作。 第一輪排查 遇到這種問題時,最重要的不是急著修復, 而是先排除錯誤假設。 於是開始逐項驗證: 重新安裝 HP 官方完整驅動 確認 Wi-Fi 連線正常 確認其他電腦可正常列印 確認印表機韌體正常 確認網路可正常 Ping 通 結果全部通過。 問題依然存在。 此時可以確定: 印表機本身並沒有壞。... » read more

收斂的委員會:Decision Convergence Engineering 的一次實踐
收斂的委員會:Decision Convergence Engineering 的一次實踐

個案經驗分享 · AI 應用實戰 · 決策工程 收斂的委員會 Decision Convergence Engineering 的一次實踐 人越多,越難收斂——這是多數人對開會的印象。但我的經驗剛好相反:當與會者全是 AI,收斂速度反而比任何真人委員會都快。 Mr. τ / 風雲網通系統 · 2026 🤔 一個違反直覺的觀察 很多人對開會的直覺是:人越多,立場越多,越難有結論。 這個直覺在真人世界裡完全正確。但當與會成員換成 AI 助理,這個規律就失效了。 我長期使用多模型合議來輔助重大決策,觀察到一件事:AI 委員會的發散速度很快,收斂速度也很快。 而且幾乎不需要主席強行裁決——觀點的碰撞本身就會自然篩選出值得保留的東西。 ⚖️ 真人委員會 vs AI 委員會 真人委員會難以收斂,不是因為人不夠聰明,而是因為人帶著太多與問題本身無關的東西進入討論: 真人委員會的阻力 AI 委員會的特性 權力鬥爭與派系利益 ✔ 無組織政治 面子問題、不願認錯 ✔ 無自我防衛 情緒反應與歷史包袱 ✔ 每次對話都是新的起點 部門本位、各守地盤 ✔ 只針對問題本身給出立場 開會時間有限、精力有限 ✔ 幾分鐘內給出有結構的完整立場 AI 之間觀點不同,但沒有任何一個模型有「贏過其他模型」的動機。它們只是在回應問題本身。這讓討論的訊噪比大幅提高。 🧭 實際流程是這樣跑的 我的主導... » read more

41 個專案之後,我才搞懂什麼叫做「知識資產」
41 個專案之後,我才搞懂什麼叫做「知識資產」

41 個專案之後,我才搞懂什麼叫做「知識資產」 AI 讓開發速度提升十倍之後,最大的敵人不再是寫程式,而是遺忘。 作者:Mr. τ/風雲網通系統  |  標籤:知識工程 PCPiLOT SMB AI 「你有沒有一個機制,讓 AI 幫你掃描、萃取、歸檔過去寫過的好東西?」 我問過很多工程師。沒有人說有。 事件:29 次掃描,0 次成功 AI 助理出現之後,有一件事悄悄發生了。 開發速度變快了。快很多。以前一年做三個專案,後來一個月可以做三個。SPA、Python 串接、API 模組、診斷小工具……專案數量在我幾乎沒有意識到的情況下,突破了四十個。 然後,遺忘開始追上來。 「哪個專案有 OAuth 模組?」「上次那個 Ollama 串接,是在哪裡寫的?」「GPU 監控的邏輯,我記得優化過,但是在哪一個專案?」——這些問題開始頻繁出現。最大的敵人,不再是開發速度,而是自己累積的東西太多、太快、太散。 我試過用程式自動比對這 41 個專案的相似度,希望找出可以重用的部分。跑了 29 次,設計了各種比對邏輯,結果全部失敗。不是技術問題,是方向錯了——我一直在找「哪裡一樣」,而不是在想「什麼值得留下來」。 發現:掃描工具的方向,一直對齊錯誤的問題 工程師寫工具,有一個慣性:從「發現問題」出發。程式碼有沒有重複?有沒有 bug?有沒有技術債? 但知識萃取需要的不是這個。開一個新案子的第一個問題,從來不是「我之前有沒有寫過類似的 bug」——而是「我之前有沒有解決過類似的需求」。 這是 PCPiLOT 工程日誌裡記下的一條教訓: 掃描工具應該對齊「開案時的需求」,而不是對齊「發現問題」。這兩個方向,工具架構完全不同。 說穿了就是:你需要的不是程式碼比對器,你需要的是架構解剖台。 抽象:三個步驟,把 41 個專案變成一座知識素材庫 我重新設計了 PCPiLOT 的專案解剖流程,分三個階段: 1 專案群組化 自動掃描目錄,排除實驗性的零散檔案,以「專案」為單位識別核心模組。不是每一個 .py... » read more