Tôi có nhóm ZFS này bao gồm hai ổ đĩa Samsung 870 QVO 1TB được nhân đôi mà tôi đã sử dụng được khoảng một năm để lưu trữ hình ảnh khách bhyve dưới dạng ZVOL.Trong thời gian đó, tôi đã tạo/gây rối/phá hủy nhiều phiên bản VM; nhóm này đã chứng kiến khá nhiều hoạt động của đĩa.
Đêm qua, khi xem xét hiệu suất I/O của đĩa trên một trong các máy ảo, tôi nhận ra rằng mình chưa bao giờ cắt bớt các ổ SSD này trước đây. Không thực sự biết điều gì sẽ xảy ra, tôi tắt máy ảo và chạy trang trí zfs trên hồ bơi.
Nhìn chung, toàn bộ hoạt động mất tới 16 giờ (!) để hoàn thành. Để tham khảo, đây là những gì gstat -pdo đã phải nói trong thời gian đó (đầu ra điển hình, với các giá trị trung bình trên 10 giây):
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d o/s ms/o %busy Name
11 45 0 0 0.0 27 292 84.9 18 8497 114.3 0 82.9 101.0| ada0
12 37 0 0 0.0 26 283 92.1 11 6547 189.1 0 84.2 100.6| ada1
Trong mọi trường hợp, tôi kiên nhẫn để nó chạy cho đến khi hoàn thành.
Sau đó, sớm hơn hôm nay và với tất cả các máy ảo vẫn dừng, tôi quyết định chạy trang trí zfs lần nữa. Lý do của tôi là vì không có hoạt động đáng kể nào trên nhóm đó kể từ TRIM trước và với hầu hết các khối chưa phân bổ được cho là đã được bộ điều khiển SSD thu hồi lần đầu tiên, nên lần này sẽ nhanh hơn nhiều.
Chà, trực giác của tôi đã sai: TRIM này hiện đã chạy được khoảng 5 giờ và theo trạng thái zpool -t, mới xong được hơn 30%. Vì vậy, rõ ràng, tôi đang xem xét thời gian chạy tổng thể tương tự (~ 16 giờ, cho hoặc nhận).
Hành vi đó có được mong đợi không? Bởi vì nếu đúng như vậy, thì rõ ràng là tôi phải thiếu điều gì đó về cách thức hoạt động của TRIM.
Ghi chú:
- Tôi nhận thức được những thiếu sót của dòng QVO (đèn flash MLC 4 bit, bộ đệm giả SLC nổi tiếng là rất nhỏ), vì vậy tôi không mong đợi bất kỳ hiệu suất điên rồ nào bắt đầu.
- Có thể có điều gì đó không ổn với thiết lập của tôi (cáp SATA xấu, v.v.), nhưng điều đó vẫn không giải thích được tại sao hệ thống dường như không được hưởng lợi từ các lần chạy TRIM trước đó trên cùng một nhóm.
