TRIM trong SSD

1. Tổng quan

TRIM là một tính năng trong chuẩn giao tiếp của SSD (ATA cho SATA SSD, UNMAP cho SCSI/SAS và tương đương trong NVMe). Mục tiêu của TRIM là cho phép hệ điều hành thông báo cho SSD biết block dữ liệu nào không còn cần thiết, từ đó SSD có thể chủ động dọn dẹp và duy trì hiệu năng ổn định.

2. Lịch sử hình thành và hỗ trợ

• SSD đời đầu (trước 2009):
  • Không hỗ trợ TRIM.
  • Khi xóa file, SSD không biết block nào đã rảnh, dẫn đến hiệu năng ghi giảm mạnh theo thời gian.
• Sau 2009:
  • TRIM được chuẩn hóa trong ATA-8 (cho SATA).
  • Windows 7 và Linux kernel 2.6.33 bắt đầu hỗ trợ TRIM.
  • Các SSD thế hệ sau đều tích hợp TRIM trong firmware.
• Hiện nay:
  • SSD consumer và enterprise đều hỗ trợ TRIM/UNMAP.
  • Tuy nhiên, một số trường hợp TRIM có thể không hoạt động nếu controller RAID hoặc adapter không truyền lệnh xuống SSD.

3. Cơ chế hoạt động của TRIM và Garbage Collection

3.1 Logic cơ bản

• Khi OS xóa file nó chỉ đánh dấu block là free, dữ liệu vẫn còn trong NAND.
• Nếu có TRIM OS sẽ gửi lệnh cho SSD báo rằng block đó có thể bỏ.
• SSD controller đánh dấu page invalid và khi Garbage Collection (GC) chạy, nó sẽ gom dọn để tạo block sạch.

NAND chỉ có thể xóa cả block lớn (ví dụ 256 KB) chứ không thể xóa từng page nhỏ nằm trong block.
Ví dụ block gồm 10 page, trong đó 8 valid (V) và 2 invalid (X):

Block X:
[ V1 ][ V2 ][ V3 ][ V4 ][ V5 ][ V6 ][ V7 ][ V8 ][ X1 ][ X2 ]

• SSD muốn giải phóng block này:
  • Copy 8 valid (V) page sang block mới.
  • Erase toàn bộ block invalid (X).
  • Block invalid (X) trở thành block sạch, lúc này nó mới sẵn sàng ghi dữ liệu mới.

Nếu có quá nhiều invalid page (nhờ TRIM) → số valid phải copy ít hơn → GC nhanh hơn → hiệu năng tốt hơn.

Hình trên sẽ mô tả cách TRIM hỗ trợ Garbage Collection trong SSD. Ta đọc từng cột (1 → 2 → 3).

Cột 1: User viết 4 file mới (A, B, C, D)

• OS logical view (người dùng nhìn thấy): 4 file được lưu: A, B, C, D.
• SSD logical view (LBAs): OS gán các file vào block logic (A1, A2… B1, B2…).
• SSD physical view: Dữ liệu được ghi xuống NAND theo block vật lý. SSD có overprovisioning (một vùng dự phòng ẩn, màu đen phía dưới).

→ Lúc này tất cả dữ liệu còn valid (còn dùng).

Cột 2: User xoá file C (OS gửi TRIM)

• OS logical view: File C biến mất, chỗ trống hiển thị là “FREE”.
• SSD logical view: OS gửi lệnh TRIM cho SSD, báo rằng các block chứa file C (C1, C2) đã free.
• SSD physical view: SSD đánh dấu các page chứa file C là invalid (ghi “GC” = Garbage Collection), nghĩa là sẽ bỏ qua chúng khi gom dữ liệu lại.

→ Lúc này, file C thực sự không còn cơ hội phục hồi (nếu TRIM đã gửi).

Cột 3: User ghi file mới E

• OS logical view: Thêm file E vào, OS báo rằng nó chiếm chỗ free.
• SSD logical view: Dữ liệu file E (E1, E2) ghi vào vị trí mới trong LBAs.
• SSD physical view: SSD không ghi chồng lên C1/C2 cũ mà ghi file E vào vùng khác sạch (overprovisioning).
• Block chứa C1/C2 sẽ được GC xử lý sau này (khi gom dọn).

→ Kết quả:

• Người dùng thấy file E thay thế file C.
• SSD thực sự ghi E ở vùng mới → giúp ghi nhanh hơn vì không cần erase block cũ trước khi ghi.

3.2. Tại sao khi lệnh TRIM đã gửi ở tầng SSD logical (chưa tới phần SSD physical ) nó đã làm cho việc cứu dữ liệu gặp khó khăn.

Khi OS gửi lệnh TRIM

• Lúc này ở tầng SSD logical view, OS nói cho SSD biết các LBA (C1, C2) này đã free, không còn chứa dữ liệu hợp lệ nữa.
• SSD controller lúc này sẽ đánh dấu invalid cho các page chứa C1, C2.

Vậy ở góc độ file system / logical recovery:

• Kể từ khi TRIM được gửi, block đó không còn được coi là chứa dữ liệu.
• Công cụ phục hồi phần mềm (testdisk, r-studio, photorec…) sẽ không thể đọc lại C1, C2 nữa, vì controller sẽ bỏ qua khi bạn yêu cầu đọc, nó không cho phép bạn thấy các block đã bị đánh dấu là invalid để khôi phục dữ liệu nữa.
• Do đó, về mặt khả năng cứu bằng software → coi như không còn khả năng cứu nữa.

Nhưng ở mức NAND vật lý

• Khi TRIM vừa gửi xong, NAND cell vẫn còn lưu điện tích (dữ liệu C1, C2 vẫn ngồi đó).
• SSD chỉ đánh dấu invalid trong bảng mapping FTL (Flash Translation Layer).
• Việc xóa thật sự (erase) chỉ xảy ra khi garbage collection gom block đó hoặc khi cần dung lượng trống.
• Cho nên:
  • Nếu can thiệp hardware level (chip-off, NAND reader) và controller chưa kịp erase → vẫn còn cơ hội đọc raw dữ liệu.
  • Nhưng việc lấy dữ liệu ở trường hợp này cũng cực kỳ khó, chỉ vài phòng lab chuyên nghiệp với PC-3000 Flash/Soft-Center mới làm nổi nhưng tỉ lệ cũng không cao.

Vì vậy trong thực tế cứu dữ liệu SSD:

• Nếu TRIM đã bật và OS đã gửi → phần lớn ca phục hồi coi như thua.
• Trừ khi hành động cực nhanh và có thiết bị chuyên dụng đọc trực tiếp NAND nhưng tỉ lệ cũng không cao.

4. Tác động của TRIM đến hiệu năng

Để có cái nhìn tổng quan về so sánh hiệu năng SSD Có TRIM vs Không TRIM, ta nhìn sơ đồ dưới.

Tốc độ ghi
(MB/s)
 400 |       Có TRIM: duy trì ổn định
     |       ------------------------------
 300 |
     |
 200 |                               
     |
 100 | Không TRIM: giảm dần theo thời gian sử dụng
     | ###########-----......               
   0 |___________________________________________
        Ban đầu   Sau vài tuần   Sau vài tháng

Trục ngang = Thời gian sử dụng
Trục dọc = Hiệu năng ghi (MB/s)

Từ sơ đồ trên bạn có thể thấy.

Có TRIM:

• SSD nhận biết sớm block free.
• Garbage Collection hiệu quả (copy ít dữ liệu valid hơn).
• Tốc độ ghi duy trì ổn định trong suốt vòng đời, chỉ giảm nhẹ khi cell NAND bị mòn.

Không TRIM:

• SSD không biết block nào invalid, phải copy cả dữ liệu rác khi GC.
• Hiệu năng ghi giảm rõ sau vài tuần/tháng sử dụng, đặc biệt khi SSD gần đầy.
• Trải nghiệm thường thấy SSD mới thì nhanh, sau đó tốc độ tụt và không phục hồi lại nếu không secure erase.

Ví dụ thực tế cho thấy

• Intel X25-M Gen1 (không TRIM) có tốc độ ghi ngẫu nhiên giảm từ 35 MB/s xuống dưới 10 MB/s sau vài tháng.
• Intel X25-M Gen2 (có TRIM) sẽ duy trì ổn định 35 MB/s trong cùng điều kiện.

5. Lời khuyên

• Luôn bật TRIM trên hệ điều hành có hỗ trợ, ví dụ Windows 7+, Linux kernel 2.6.33+,…
• Không nên để SSD đầy, nên chừa ít nhất 10–20% dung lượng trống.
• Khi dùng RAID hardware, kiểm tra xem controller có hỗ trợ pass-through TRIM/UNMAP không.
• Nếu khi cần phục hồi dữ liệu khi nghi ngờ xóa nhầm, cần ngắt nguồn ngay để tránh TRIM và GC dọn block.

6. Kết luận

TRIM là cơ chế quan trọng giúp SSD nhận diện sớm dữ liệu không còn cần thiết, từ đó tối ưu quá trình Garbage Collection, giảm write amplification và duy trì hiệu năng lâu dài. Những SSD không có TRIM (đời cũ hoặc bị chặn bởi controller) thường bị tụt tốc độ nghiêm trọng sau một thời gian sử dụng. Trong bối cảnh ngày nay, TRIM gần như là một tính năng bắt buộc để SSD hoạt động ổn định và hiệu quả.