SSD cache TrueNAS: 2 NVMe dùng L2ARC, SLOG hay Metadata?

"SSD cache" trên TrueNAS thật ra là ba vai khác nhau

ZFS không có nút "SSD cache". Mở màn hình tạo pool, bạn gặp ba mục Cache, Log và Metadata, tức ba vai riêng: L2ARC, SLOG và special vdev. Kịch bản quen thuộc: mua 2 thanh NVMe, chọn đại một mục, chép thử file phim, tốc độ y như cũ. Tiền thì đi, tốc độ thì ở lại.

Trả lời ngắn gọn: NAS gia đình nên gộp 2 NVMe thành pool mirror riêng cho Apps và VM. Chỉ dùng làm Cache, Log hay Metadata khi số đo chỉ đúng nút thắt đó. Mới nghe tên TrueNAS thì đọc TrueNAS là gì trước. Chuyện ARC và RAM đã có bài TrueNAS cần bao nhiêu RAM, ở đây không viết lại.

Ba vai tăng tốc ba việc khác nhau:

• Cache (L2ARC): đọc lặp lại trên tập dữ liệu lớn hơn RAM, ví dụ ảnh đĩa VM hoặc dữ liệu nóng nhiều người cùng mở.
• Log (SLOG): chỉ ghi sync. Ghi async đi qua RAM và không dùng SLOG.
• Metadata (special vdev): duyệt thư mục và file nhỏ, đổi lại hỏng là hỏng cả pool.

Cả ba đều không phải cache ghi để chép file nhanh hơn. Người từ Synology quen một mục SSD Cache đọc/ghi duy nhất nên hay đi tìm cái tương đương, và tìm mãi không ra: TrueNAS tách thành ba vai độc lập, mức rủi ro rất khác nhau.

Ba tình huống cho dễ hình dung:

• Gia đình, 4 khay, 16–32GB RAM, chép ảnh/phim qua SMB: thêm Cache hay Log gần như không đổi tốc độ chép. Nút thắt thường là mạng: khoảng 110 MB/s với 1GbE và 280 MB/s với 2.5GbE (số tính nhẩm, không phải số đo). SSD nhanh mấy cũng không chui qua được sợi cáp đó.
• Homelab chạy Immich, Jellyfin và VM trên pool HDD: app ì vì ổ cơ. Chuyển sang pool NVMe mirror có lợi rõ nhất mà không đặt pool HDD vào rủi ro.
• Văn phòng nhỏ dùng NFS/iSCSI cho ESXi hoặc Proxmox, VM buộc nằm trên HDD: đây mới là lúc SLOG có PLP có việc để làm. Forum ghi nhận một ca Optane làm SLOG tăng IOPS 3–5 lần trong fio, nhưng đó là số của một người dùng trên pool SSD, đừng coi là cam kết.

Cache, Log, Metadata nằm ở đâu trong wizard tạo pool

Trên 25.10, wizard đi theo thứ tự General Info > Data > Log > Spare > Cache > Metadata > Dedup > Review. Spare và Dedup không thuộc phạm vi bài này.

Về số thanh: Cache chỉ cần 1 thanh và luôn stripe. Log dùng 1 hoặc 2. Metadata tối thiểu là mirror, mức chịu lỗi phải bằng hoặc cao hơn data vdev. Riêng pool toàn mirror/stripe thì gỡ được Metadata nếu đủ điều kiện.

Tính tới 09/11/2026, bản ổn định mới nhất là TrueNAS Community Edition (dòng SCALE cũ) 25.10.8 "Goldeye", phát hành 05/11/2026, dùng ZFS 2.3. TrueNAS 27 đang ở 27.0.0-RC.1 cho Early Adopter, dùng OpenZFS 2.4.4, bản chính thức dự kiến đầu 12/2026. Tên menu trong bài theo 25.10. Docs 27 gom vào bước "Optional VDEVs" và gọi Metadata là Special.

CORE dừng ở 13.3-U1.2 và không còn phát triển tích cực, nên mình không khuyên đầu tư phần cứng mới cho nó. Máy CORE đang chạy thì dùng màn hình Pool Manager, loại vdev Metadata. Bản 13.3 đã bỏ web shell nên lệnh phải chạy qua SSH.

Vì sao mặc định là pool NVMe mirror

• Làm hoàn toàn bằng GUI, không đụng vào pool HDD đang chạy.
• Lợi ích thấy ngay với app và VM, không cần đoán ARC hit ratio hay hành vi sync.
• Hai thanh hỏng cùng lúc chỉ mất pool app/VM, khôi phục được từ bản replicate. Pool dữ liệu chính vẫn an toàn.

Forum có ý kiến khuyên dùng 2 NVMe làm mirror special vdev. Mình không chọn làm mặc định, vì trên pool RAIDZ đó là quyết định không đảo ngược được. Chia partition một thanh cho nhiều vai cũng bỏ qua: đó là thủ thuật CLI, ngoài luồng GUI, và không có docs chính thức nào hỗ trợ trong các nguồn đã đọc.

Đo trước khi rút ví

Mở Shell hoặc SSH rồi chạy bộ lệnh đúng phiên bản. OpenZFS 2.4 đã đổi tên lệnh, và chưa xác nhận được TrueNAS 27 có giữ tên cũ không. Báo không tìm thấy lệnh thì dùng cột bên phải.

Cờ -s archits mới được kiểm trên man page của zarcsummary. Nếu báo lỗi, chạy báo cáo đầy đủ rồi tìm phần hit ratio. zilstat có trong man page OpenZFS nhưng chưa xác nhận TrueNAS cài sẵn. Còn màn hình Reporting > ZFS, docs 25.10 chỉ xác nhận biểu đồ ARC size, nên dùng lệnh chắc hơn.

Ngưỡng tham khảo, theo kinh nghiệm forum chứ không phải chuẩn chính thức: ARC hit khoảng 90% là mục tiêu, L2ARC hit từ 20% trở lên là tốt. Đo sau vài ngày dùng bình thường, đừng đo ngay sau khi khởi động lại.

Khi nào từng vai thật sự có việc làm

L2ARC: bước thử rẻ và gỡ được

Xem phim hay backup đọc tuần tự không lặp lại thì L2ARC ít giúp được gì. TrueNAS cũng nói rõ L2ARC "isn't a substitute for adequate memory". Bản thân nó còn tốn RAM: mỗi block mất 96 byte header, tính bằng (dung lượng KB ÷ recordsize KB) × 96.

Với 1TB, con số là khoảng 94MB ở record 1M, 750MB ở 128K và 6GB ở 16K. Vì phụ thuộc recordsize, đừng nhớ một tỉ lệ RAM/L2ARC cố định. RAM tối thiểu cho L2ARC thì forum còn mâu thuẫn: có ý kiến nói 64GB, hướng dẫn của Arwen nói 16GB vẫn dùng được. Cứ dựa vào hit ratio.

Muốn L2ARC chỉ cache metadata, dùng lệnh dưới đây. Chưa thấy trường GUI tương ứng trong docs đã kiểm.

zfs set secondarycache=metadata <pool/dataset>

SLOG: không phải cache ghi

ZFS chỉ đọc lại log sau sự cố. Vì vậy câu hỏi đầu tiên luôn là: workload của bạn có ghi sync không?

• SMB: gần như không đổi với chép file thường. Samba mặc định strict sync = yes nên client vẫn có thể yêu cầu flush. Hành vi của Time Machine chưa xác minh được, nên đo thay vì đoán.
• NFS: client quyết định, và ESXi luôn sync.
• iSCSI: không tự động sync hết. Bài forum cũ của jgreco ghi "by default, iSCSI writes are async" và khuyên sync=always cho VM. Docs TrueNAS cũng lấy iSCSI làm ví dụ cho Sync=Always. SLOG chỉ có việc khi zvol đặt Sync=Always hoặc initiator gửi lệnh sync.

Thuộc tính Sync có ba giá trị: Standard (mặc định), Always, Disabled. Với dataset, bạn chỉnh nó trong phần sửa dataset ở màn hình Datasets. Về kích thước, docs khuyên 16GB, over-provision từ SSD lớn hơn, và tốc độ ghi của thiết bị phải cao hơn lưu lượng ghi sync dự kiến.

PLP thì jgreco viết thẳng: "not something that should be considered optional". Ổ không PLP dễ thành SLOG yếu. Còn mirror hay không: docs khuyên mirror vì log không mirror có thể mất các ghi sync gần nhất, forum lại cho rằng NAS nhỏ một thanh thường đủ. Tùy bạn chịu được rủi ro đó tới đâu.

Metadata: nhanh thật, nhưng là đường một chiều

Special vdev tăng tốc duyệt thư mục và file nhỏ, không tốn RAM như L2ARC. Đổi lại, nó hỏng thì pool hỏng, không truy cập được dữ liệu.

Điểm dễ bỏ sót: pool RAIDZ2 cần mirror 3 thanh. Docs 27 ghi: "Pool creation fails when the special VDEV redundancy is lower than the data VDEV redundancy." Nên 2 NVMe chỉ đủ cho pool Mirror hoặc RAIDZ1.

Trên pool RAIDZ, docs nói rõ "a metadata VDEV is a permanent addition". Dữ liệu cũ không tự chuyển sang, nên tốt nhất thêm trước khi chép dữ liệu. Nếu SSD có cache trong mà không có PLP, docs khuyên dùng UPS.

Metadata khoảng 0,3% dung lượng pool là con số kinh nghiệm, các báo cáo dao động từ 0,1% đến 2,6%, nên phải đo. Lệnh dưới đây lấy từ forum, nguồn ghi cho CORE 13.0-U6 trở lên, chưa kiểm trên 25.10. Giữ vdev dưới khoảng 75% đầy; khi đầy, dữ liệu tràn lại xuống vdev thường.

zdb -LbbbA -U /data/zfs/zpool.cache <pool>

Muốn đẩy file nhỏ sang đây, dùng trường Metadata (Special) Small Block Size trong Advanced Options, mặc định 0, nhận 0 hoặc lũy thừa 2 từ 512B đến 1M. Từ TrueNAS 27 mới có thêm: ZIL nằm trên special vdev khi không có log vdev, block zvol đi vào special qua special_small_blocks, và giá trị này không cần là lũy thừa 2, tối đa 16 MiB. Đừng tìm các tính năng đó trên 25.10.

Quy ra tiền: "thêm RAM trước" còn đúng không?

Giá dưới đây lấy từ trang sản phẩm mở trực tiếp ngày 09/11/2026. Giá đổi nhanh, hỏi lại trước khi mua.

Giá DC2000B chỉ lấy từ một shop, không rõ ngày cập nhật. Tính theo GB, NVMe khoảng 4.300–8.300đ, DDR4 khoảng 180.000–237.000đ, DDR5 khoảng 420.000–500.000đ. Từ đó ra ba kết luận, khá khác lời khuyên chung trên forum nước ngoài:

• Máy DDR4 còn khe trống: 32GB RAM (5,8–7,6 triệu) rẻ hơn 2 NVMe 1TB (từ 8,6 triệu), nên "thêm RAM trước" vẫn đúng.
• Máy DDR5: 32GB RAM từ 13,5 triệu, đắt hơn 2 thanh NV3. Nếu ARC hit thấp, thử L2ARC một thanh khoảng 4,3 triệu là bước rẻ và gỡ được.
• SLOG mirror 2 thanh DC2000B 240GB: khoảng 8 triệu, số tiền đáng hỏi lại nếu NAS chỉ chạy SMB.

Máy nhận ECC thì hỏi thêm giá ECC UDIMM 16GB. Kingston KSM32ED8/16HD đang ghi 2.099.000đ ở Hacom, rẻ hơn RAM thường cùng dung lượng, nên có thể giá đã cũ.

Chọn ổ theo đúng vai

Cả năm dòng đều bảo hành 5 năm. SN700 chỉ là PCIe 3.0, nhưng lý do chọn nó là độ bền: 2.000 TBW cho bản 1TB, gấp ba SN7100. Cần Gen4 thì IronWolf 525 là lựa chọn cân bằng. Hai model này chưa tìm được giá VN đang bán; SN700 thì hỏi nashub.

Với DC2000B, nhìn thêm tốc độ: bản 240GB ghi tuần tự 400 MB/s, bản 480GB 800 MB/s (350 TBW), và tốc độ ghi của SLOG phải vượt lưu lượng ghi sync. Micron 7450 PRO hay Samsung PM9A3 chưa thấy giá VN. Listing Micron 1.92TB tìm được lại là M.2 22110, nên kiểm tra độ dài khe trước khi mua.

Còn pool HDD chính, chọn theo số khay và tải:

• Gia đình/SOHO, tải nhẹ: WD Red Plus chạy êm, hỗ trợ tới 8 khay. Seagate IronWolf có IronWolf Health Management và thêm dịch vụ cứu dữ liệu 3 năm. Muốn 7200 RPM ở phân khúc phổ thông thì có Toshiba N300.
• Nhiều khay hoặc tải nặng: nâng lên WD Red Pro, hoặc IronWolf Pro nếu cần dung lượng tới 32TB.

Làm pool mirror từng bước

1. Vào Storage Dashboard > Create Pool, đặt tên, chọn layout Mirror với 2 NVMe. Bỏ qua Log, Cache, Metadata.
2. Vào màn hình Installed của Apps, chọn Configuration > Choose Pool, tích Migrate existing applications. Docs cũng gọi mục này là Settings, nên nhìn nhãn trên máy bạn. Tùy chọn này không chuyển dữ liệu trong host path, phần đó bạn phải tự lo.
3. Tạo VM ở Virtual Machines > Add, đặt zvol trên pool NVMe.
4. Tạo dataset đích trên pool HDD, rồi vào Data Protection > Replication Tasks > Add, đặt Source và Destination đều là On this System.
5. Chạy thử task một lần và vào dataset đích xem có dữ liệu. Mirror không phải backup, chưa thấy bản sao thì chưa xong.

Nếu số đo bảo phải thêm vai vào pool đang chạy: Storage Dashboard > View VDEVs > Add VDEV, chọn loại, Save and Go to Review, rồi Update Pool.

Gỡ thì vào View VDEVs, bấm thiết bị, chọn Remove trong widget ZFS Info. Không thấy nút nghĩa là chưa đủ điều kiện. Gỡ vdev khỏi pool mirror/stripe cần cùng ashift, đã tải khóa dataset mã hóa và còn đủ dung lượng. Lỗi gỡ log vdev đã được sửa ở 25.10.3, máy cũ hơn thì cập nhật trước.

Lỗi hay gặp

• Mua Log để chép SMB nhanh hơn: ghi async không dùng SLOG. Kiểm tra workload có ghi sync không trước khi mua.
• Đặt Sync=Disabled để "tăng tốc": nhanh thật, y như tháo phanh xe cho nhẹ. Docs ghi chỉ hợp khi chấp nhận mất dữ liệu lúc sập máy hoặc mất điện, còn với VM thì forum cảnh báo có thể hỏng đĩa ảo.
• Thêm Metadata lên pool RAIDZ để thử: không gỡ lại được, cách quay lui thực tế là chuyển dữ liệu sang pool khác. Muốn thử thì thử Cache trước.
• Dùng 2 thanh Metadata cho RAIDZ2: không đủ mức chịu lỗi. Trông vào Spare cũng không chắc: docs 27 nói hot spare chỉ kích hoạt ở data vdev, docs 25.10 lại gợi ý thêm hot spare. Dựa vào độ sâu mirror.
• Chờ dữ liệu cũ tự sang special: chỉ dữ liệu ghi mới mới vào. zfs rewrite có trong man OpenZFS 2.3 nhưng man không nói về metadata, bản ghi forum cho thấy không chuyển hết, lại có thể tăng dung lượng dùng khi có snapshot.
• Đặt small block ≥ recordsize: cả dataset sẽ nằm trên SSD và làm đầy special vdev.
• L2ARC quá lớn trên pool lớn: persistent L2ARC bật mặc định từ 24.04 và có thể làm khởi động lại chậm đáng kể. Record nhỏ thì header còn ăn nhiều RAM hơn.
• Dùng tên lệnh cũ trên TrueNAS 27: arc_summary có thể báo không tìm thấy, đổi sang zarcsummary.

Trước khi chốt đơn

Tự hỏi đúng một câu: NAS của mình đang chậm ở việc gì? Chép file qua mạng thì nhìn lại sợi cáp. App và VM ì thì làm pool NVMe mirror. Số đo chỉ vào đọc lặp lại, ghi sync hay metadata thì mới gọi tới Cache, Log, Metadata, và nhớ Metadata là vé một chiều trên pool RAIDZ.

Khi 27.0 ra mắt, đối chiếu lại tên lệnh và nhãn giao diện trước khi làm theo. Hai thanh NVMe đặt đúng chỗ thì app chạy như thay máy mới. Đặt sai chỗ thì bạn sở hữu hai món đồ trang trí rất đắt, nằm khuất trong thùng máy, không ai ngắm được.