xác minh độc lập rằng TRIM thực sự hoạt động trên SSD


13

Tôi có một LUKSphân vùng /dev/sda1mà tôi luksOpen với --allow-discards:

cryptsetup --allow-discards luksOpen /dev/sda1 root

Sau đó tôi gắn ext4hệ thống tập tin với discardtùy chọn:

grep /dev/mapper/root /proc/mounts
/dev/mapper/root / ext4 ro,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl 0 0

Sau đó tôi cắt không gian trống trên phân vùng được gắn kết:

fstrim -v /

với df, tôi thấy /có 80% không gian trống. Điều đó có nghĩa là trên /dev/sda1, 80% đĩa là số không nhị phân.

Nếu tôi sao chép hình ảnh với cat

cat /dev/sda1 > sda1.img

và nén hình ảnh với xz, tôi hy vọng tất cả các số không trên đĩa sẽ được nén. Vì 20% dữ liệu trên đĩa được mã hóa, nên nó trông giống như ngẫu nhiên và không thể nén được. Do đó, hình ảnh nén xz phải là aprox. 20% kích thước thô.

Tuy nhiên, hình ảnh nén xz thu được có kích thước tương đương với ảnh gốc.

Là lý luận của tôi đúng?

Tại sao lý thuyết của tôi không chuyển thành thực tiễn?


2
unix.stackexchange.com/a/85880/30851 và cũngdmsetup table | grep allow_discards
frostschutz

Câu trả lời:


8

Logic của bạn không sai. Nhưng nó chỉ có giá trị nếu một số điều kiện được thỏa mãn.

Lệnh TRIM , như được chỉ định trong bộ lệnh ATA , có thể hoặc không thể tạo ra các thành phần mà nó được ban hành.
Trên thực tế, tiêu chuẩn tập trung vào những dữ liệu nào phải được trả về sau khi TRIM được ban hành 1 :

Các hành vi sau được quy định bởi tiêu chuẩn này cho các lĩnh vực mà thiết bị cắt (xem 7.5.3.3):

a) không xác định - dữ liệu phản hồi việc đọc từ một khu vực bị cắt có thể thay đổi cho mỗi lần đọc cho đến khi khu vực đó được ghi bởi máy chủ;
b) Đọc xác định sau khi cắt (DRAT) - dữ liệu được trả về khi đọc của một khu vực bị cắt không thay đổi, nhưng có thể khác với dữ liệu được trả về trước đó; và
c) Đọc số không sau khi cắt (RZAT) - dữ liệu được trả về để phản hồi lại số lần đọc của khu vực được cắt là bằng không.

[...] Đối với cả DRAT và thiết bị lưu trữ không xác định, dữ liệu được trả về để đáp lại lệnh đọc cho LBA đã được cắt xén thành công:

a) có thể là dữ liệu được trả về trước đó cho LBA được chỉ định;
b) có thể là một mẫu được tạo ra bởi thiết bị lưu trữ; và
c) không phải là dữ liệu trước đây được ghi vào một LBA khác bởi máy chủ.

Do đó, những gì thiết bị của bạn trả về sau fstrimphụ thuộc vào các tính năng mà thiết bị thực hiện. Trừ khi nó hỗ trợ RZAT, giả định rằng dữ liệu đọc từ thiết bị được cắt sẽ chỉ là số không không giữ.

Bạn có thể sử dụng hdparmđể kiểm tra điều này:

sudo hdparm -I /dev/sdX | grep -i trim

Tôi đã thực hiện một số thử nghiệm bằng cách sử dụng hai ổ SSD sdasdb. Cùng một nhà sản xuất, các mô hình khác nhau, với sự phù hợp ATA khác nhau:

$ sudo hdparm -i /dev/sdb
 ...
 Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7
 ...

$ sudo hdparm -i /dev/sda
 ...
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7
 ...

Hai ổ SSD có hỗ trợ TRIM khác nhau:

$ sudo hdparm -I /dev/sda | grep -i trim
           *    Data Set Management TRIM supported (limit 1 block)

$ sudo hdparm -I /dev/sdb | grep -i trim
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM

Tôi có thể xác nhận rằng, sau khi phát hành fstrim, ổ đĩa hỗ trợ "ZERO đọc xác định sau TRIM" (RZAT) dường như thực sự đã loại bỏ hoàn toàn phân vùng liên quan. Ngược lại, ổ đĩa khác dường như bằng không (hoặc thay thế bằng một số mẫu có khả năng nén cao) chỉ là một phần nhỏ của không gian được giải phóng.

1 Nguồn trực tuyến: THU NHẬP 529: Công nghệ thông tin - Bộ lệnh ATA / ATAPI - 4 (ACS-4)


Lưu ý khi kiểm tra:

Như được chỉ ra bởi frostschutz trong các bình luận, việc đọc sau fstrimcó thể trả về dữ liệu từ bộ đệm của hệ điều hành chứ không phải từ thiết bị được cắt xén. Đó là, ví dụ, những gì đã xảy ra trong quá trình đốt cháy này .
(Tôi cũng sẽ chỉ ra câu trả lời này cho cùng một câu hỏi cho một phương pháp thay thế để kiểm tra TRIM).

Giữa fstrimvà lần đọc tiếp theo, bạn có thể cần bỏ bộ đệm, ví dụ:

echo 3 | sudo tee /proc/sys/vm/drop_caches

Tùy thuộc vào kích thước của phân vùng bạn đang chơi, không bỏ bộ đệm có thể đủ để thử nghiệm của bạn thất bại.


Lưu ý về thiết lập của bạn:

Các discardgắn kết tùy chọn cho phép TRIM liên tục, tức là bất kỳ tập tin thời gian sẽ bị xóa. Nó không được yêu cầu bởi fstrim. Thật vậy, TRIM theo yêu cầu và TRIM liên tục là hai cách khác nhau để quản lý các hoạt động TRIM. Để biết thêm thông tin, tôi sẽ chỉ đến ổ đĩa trạng thái rắn trên Arch Linux Wiki, nơi có phạm vi chi tiết về vấn đề này.


Linux cũng có thể trả về dữ liệu khác không từ bộ đệm của mình sau TRIM, mặc dù SSD sẽ đọc lại dưới dạng số không. Đây là một vấn đề với bài kiểm tra yes-trim của tôi ở đó unix.stackexchange.com/a/85880/30851 nhưng cũng có thể liên quan đến việc đọc dữ liệu thô trước và sau TRIM. Vì vậy, nếu bạn không nhận được số 0 khi bạn mong muốn, hãy bỏ bộ nhớ cache trong trường hợp.
frostschutz

@frostschutz Điểm tốt! Tôi bằng cách nào đó đã giả định rằng, vì OP đã đề cập đến âm lượng "gốc", nó sẽ quá lớn đối với một phần quan trọng của nó để phù hợp với bộ nhớ. Nhưng chắc chắn bộ nhớ cache đã xảy ra theo cách của tôi trong các thử nghiệm của mình - điều đó đã thất bại thảm hại cho đến khi tôi bắt đầu bỏ nó. Tôi sẽ cập nhật câu trả lời của tôi.
fra-san

2

SSD có lớp mã hóa phần cứng tích hợp không? Nếu nó có một, thì các khối TRIMmed có thể là số không (hoặc có thể là tất cả) ở cấp phần cứng thô, nhưng vì máy tính nhìn thấy chúng qua lớp mã hóa, chúng sẽ xuất hiện dưới dạng giả ngẫu nhiên sau khi vượt qua tất cả -Xóa khối thô thông qua quá trình giải mã.

Một lớp mã hóa phần cứng như vậy sẽ có một số lợi thế:

  • Nó sẽ cho phép chức năng xóa bảo mật rất nhanh: chỉ cần ổ đĩa phá hủy khóa gốc được sử dụng trong lớp mã hóa phần cứng và thay thế nó bằng một cái mới và tất cả dữ liệu sẽ ngay lập tức không thể phục hồi cho hầu hết các mục đích thực tế.
  • Vì tất cả các dữ liệu đạt mức phần cứng thô sẽ được mã hóa, nó sẽ được đảm bảo trông giả ngẫu nhiên và do đó phần lớn là đồng nhất. Điều này có thể giúp tránh các điểm nóng / lạnh và đơn giản hóa ước tính hao mòn rất nhiều.


0

df báo cáo không gian trống không ngụ ý không gian trống.

trimbáo cho thiết bị lưu trữ rằng các khối không được sử dụng. Tôi không nghĩ rằng điều này làm họ thất vọng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.