QuTS hero 6.0 公開測試版——初步測試回饋（TS-264）

Beta 計劃存檔 QuTS hero h6.0 Beta
1

QuTS hero 6.0 公開測試版 – 初步測試回饋（TS-264）

測試環境

  • NAS： TS-264

  • 作業系統： QuTS hero 6.0（公開測試版）

  • 儲存： RAID 0（非關鍵 / 測試資料）

  • 使用情境： 功能與效能健全性測試（UI、SMB、快照、日誌）

:star: 第一印象

我的第一印象是非常正面。
UI感覺比以往的QuTS hero版本更快、更流暢且更現代化。頁面幾乎瞬間載入，不需要反覆重新整理頁面才能正確顯示。整體可用性與視覺一致性明顯提升。

:bar_chart: 系統閒置資源

開機後閒置約5分鐘：

  • CPU平均使用率： 約4.1%

  • 記憶體使用量： 約6.37 GB / 15.41 GB

系統感覺輕快且反應靈敏，沒有明顯的背景資源突增。

:globe_with_meridians: SMB效能測試

單一大型檔案（約16 GB），Windows PC ↔ NAS透過SMB：

  • PC → NAS： 約280 MB/s

  • NAS → PC： 約280 MB/s

傳輸穩定，未出現斷線、當機或重試。
QuLog與通知在傳輸期間及之後都完全乾淨。

:camera_with_flash: 快照健全性檢查

  • 在共享資料夾Public建立快照

  • 快照狀態：已就緒

  • 快照大小：約208 KB

  • 快照類型：Crash consistent

  • 快照刪除：成功

  • QuLog未記錄任何警告或錯誤

快照操作速度快，且完全符合預期。

:receipt: 日誌與通知

  • QuLog Center： 乾淨（警告/錯誤篩選）

  • Notification Center： 無異常警示

  • 登出行為： 即時登出，無延遲（顯著改善）

開機後觀察到一次性非阻斷日誌記錄：

「QuTS hero 不支援此版本的 CacheMount。請前往 App Center 或 QNAP 官網檢查應用程式更新……」

備註：

  • 僅出現一次

  • CacheMount 在此測試版的 App Center 或 QNAP 官網均不可用

  • 未發現任何功能性影響

:magnifying_glass_tilted_left: 整體評價

目前為止，QuTS hero 6.0 公開測試版感覺成熟、快速且穩定：

  • UI反應明顯提升

  • SMB效能優異

  • 快照行為乾淨

  • 日誌乾淨

  • 基本日常操作未見回歸問題

這是一個非常有潛力的測試版。

感謝有機會測試 QuTS hero 6.0。如有新發現，我會持續測試並提供更多回饋。

2

AI垃圾。

3

這是基於我在 TS-264 上的實際測試。
SMB 傳輸（約 16 GB）通過 \\\\IP\\Public\\TEST_COPY 測試，雙向速度約為 280 MB/s。
已在 Snapshot Manager（快照管理器）中驗證快照的建立/刪除（狀態為 Ready，約 208 KB）。
開機後在 QuLog 中觀察到一次性 CacheMount 相容性訊息。
如果你需要任何特定細節，請告訴我。

4

我所有的設備現在都運行 QuTS hero 6.0 公開測試版。

TS-473A - 32 TB

TS-464 - 16TB

2 台 TS-264 - 各 16TB

5

其他觀察（QuTS hero 6.0 公開測試版）

在進一步測試過程中，我注意到兩個可能值得調查的 UI 問題：

  1. 登出時卡住/凍結
    至少有一次，點擊 登出 後，網頁 UI 發生了卡住/凍結的情況，未能正常登出。會話未完成登出流程，需要手動關閉分頁或重新載入來恢復。

  2. 資料夾的「內容」視窗為空白
    當我在 File Station 右鍵點擊資料夾並選擇內容時，內容對話框有時會以空白/無內容的視窗打開（未顯示任何細節）。需要關閉並重新打開，但此行為不一致。

在我的測試過程中，其他部分都保持穩定；這兩個項目看起來像是 UI/UX 回歸問題，而非儲存/網路的功能性問題。

6

在 QuTS hero 6.0 beta 的其他觀察：
當使用者手動登出時，登出流程運作正常。
然而，若網頁介面長時間開啟，當工作階段逾時觸發自動登出時，
此時 UI 會卡在載入畫面，且不會自動導向登入頁面。
必須手動重新整理瀏覽器，才能完成登出流程。

7

此外，在隨後成功登入後，網頁介面可能會以損壞或無法使用的狀態載入，需要再次手動重新整理頁面才能正確顯示。

已在**Brave 瀏覽器（Windows 11）**上測試。

8

將「/usr/local/lib/libtrash.so」預載（preload）通常是非常糟糕的做法！
我使用 Entware OPKG 來自訂和自動化一些流程。在我的特殊情況下，我修改了 HBS3 腳本來自動開啟和關閉我的外接硬碟。這些都是 shell 腳本，使用來自 Entware 的修改版 busybox 1.37。
在這個 beta 版本之前，我的腳本運作都沒有問題，但這個 beta 版本卻用了非常不乾淨的手法，普遍預載這個「libtrash.so」，在執行 shell 腳本之前就載入。這導致執行 nc（來自 busybox 的 netcat）時出現錯誤：

/opt/bin/nc: /opt/lib/libc.so.6: version `GLIBC_2.33’ not found (required by /usr/local/lib/libtrash.so)

/opt/bin/nc: /opt/lib/libc.so.6: version `GLIBC_2.34’ not found (required by /usr/local/lib/libtrash.so)

我針對我的特殊情況找到了一個變通方法，在 shell 腳本中清除了 LD_PRELOAD。然而，使用這種不乾淨的技巧真的很糟糕，也無法體現 QNAP 的程式品質。

9

您好，根據我們的內部分析，此問題似乎與 6.0 版本的工具鏈（toolchain）更新有關。由於您的 BusyBox 並非使用此特定工具鏈建構，因此與系統的函式庫不相容。

我們認為這並不是由 PRELOAD 本身直接導致的；而是 PRELOAD 會強制程式使用我們的系統函式庫，從而暴露出這個不相容的問題。

我們計劃在 6.0 正式版發佈後，釋出本版本所需的開源元件。屆時您可以嘗試重新編譯您的工具，理論上應該可以解決這個問題。謝謝！