verifikasi secara independen bahwa TRIM memang berfungsi pada SSD

13

Saya memiliki LUKSpartisi /dev/sda1yang saya luksOpen dengan --allow-discards:

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

Saya kemudian me-mount sistem ext4file dengan discardopsi:

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

Saya kemudian memangkas ruang kosong pada partisi yang terpasang:

fstrim -v /

dengan df, saya melihat /memiliki ruang kosong 80%. Itu berarti bahwa pada /dev/sda1, 80% dari disk adalah nol biner.

Jika saya mengkloning gambar dengan cat

cat /dev/sda1 > sda1.img

dan kompres gambar dengan xz, saya harapkan semua nol pada disk dikompresi. Karena 20% dari data pada disk dienkripsi, itu harus terlihat seperti acak dan tidak terkompresi. Oleh karena itu, gambar yang dikompresi xz harus aprox. 20% dari ukuran mentah.

Namun, gambar yang dikompresi xz kira-kira berukuran sama dengan aslinya.

Apakah alasan saya benar?

Mengapa teori saya tidak diterjemahkan ke dalam praktik?

Martin Vegter
sumber
2
unix.stackexchange.com/a/85880/30851 dan jugadmsetup table | grep allow_discards
frostschutz

Jawaban:

8

Logika Anda tidak salah. Tetapi itu hanya valid jika beberapa persyaratan dipenuhi.

The perintah TRIM , sebagaimana ditentukan dalam ATA perintah set , mungkin atau mungkin tidak nol sektor itu dikeluarkan terhadap.
Sebenarnya, standar ini berfokus pada data apa yang harus dikembalikan setelah TRIM dikeluarkan 1 :

Perilaku tindak ditentukan oleh standar ini untuk sektor-sektor yang dipangkas perangkat (lihat 7.5.3.3):

a) non-deterministik - data dalam menanggapi pembacaan dari sektor yang dipangkas dapat berubah untuk setiap pembacaan sampai sektor ini ditulis oleh tuan rumah;
b) Deterministic Read After Trim (DRAT) - data yang dikembalikan sebagai respons terhadap pembacaan sektor yang dipangkas tidak berubah, tetapi mungkin berbeda dari data yang sebelumnya dikembalikan; dan
c) Baca Zeroes After Trim (RZAT) - data yang dikembalikan sebagai respons terhadap pembacaan sektor yang dipangkas adalah nol.

[...] Untuk DRAT dan perangkat penyimpanan non-deterministik, data dikembalikan sebagai respons terhadap perintah baca ke LBA yang telah berhasil dipangkas:

a) mungkin data yang sebelumnya dikembalikan untuk LBA yang ditentukan;
b) mungkin merupakan pola yang dihasilkan oleh perangkat penyimpanan; dan
c) bukan data yang sebelumnya ditulis ke LBA yang berbeda oleh tuan rumah.

Jadi, apa yang dikembalikan perangkat Anda fstrimtergantung pada fitur yang diterapkannya. Kecuali jika ia mendukung RZAT, asumsi bahwa data yang dibaca dari perangkat yang dipangkas hanya nol yang tidak berlaku.

Anda dapat menggunakan hdparmuntuk memeriksa ini:

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

Saya melakukan beberapa tes menggunakan dua SSD, sdadan sdb. Pabrikan yang sama, model yang berbeda, dengan kesesuaian ATA yang berbeda:

$ 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
 ...

Kedua SSD memiliki dukungan berbeda untuk TRIM:

$ 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

Saya dapat mengkonfirmasi bahwa, setelah mengeluarkan fstrim, drive yang mendukung "Deterministic read NERO after TRIM" (RZAT) tampaknya benar-benar memusatkan perhatian pada partisi yang bersangkutan hampir seluruhnya. Sebaliknya, drive lain tampaknya memusatkan perhatian (atau diganti dengan beberapa pola yang sangat kompresibel) hanya sebagian kecil dari ruang yang dibebaskan.

1 Sumber online: INCITS 529: Teknologi informasi - ATA / ATAPI Command Set - 4 (ACS-4)


Catatan tentang pengujian:

Seperti yang ditunjukkan oleh frostschutz dalam komentar, baca setelah fstrimdapat mengembalikan data dari cache sistem operasi, dan bukan dari perangkat yang dipangkas. Misalnya, apa yang terjadi dalam qustion ini .
(Saya juga akan mengarahkan jawaban ini ke pertanyaan yang sama untuk metode alternatif untuk menguji TRIM).

Antara fstrimdan bacaan berikutnya Anda mungkin perlu menjatuhkan cache, misalnya dengan:

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

Bergantung pada ukuran partisi yang Anda mainkan, tidak menjatuhkan cache mungkin cukup untuk pengujian Anda gagal.


Catatan pada pengaturan Anda:

The discardmount option memungkinkan TRIM terus menerus, yaitu file waktu akan dihapus. Tidak diwajibkan oleh fstrim. Memang, TRIM atas permintaan dan TRIM berkelanjutan adalah dua cara berbeda untuk mengelola operasi TRIM. Untuk informasi lebih lanjut, saya akan menunjuk ke solid state drive di Arch Linux Wiki, yang memiliki cakupan terperinci tentang masalah ini.

fra-san
sumber
Linux mungkin juga mengembalikan data bukan nol dari cache setelah TRIM, meskipun SSD akan membacanya kembali sebagai nol. Ini adalah masalah dengan tes ya-trim saya di sana unix.stackexchange.com/a/85880/30851 tetapi mungkin juga terkait dengan membaca data mentah sebelum dan sesudah TRIM. Jadi, jika Anda tidak mendapatkan nol saat Anda mengharapkannya, jatuhkan cache untuk berjaga-jaga.
frostschutz
@frostschutz Poin bagus! Entah bagaimana saya berasumsi bahwa, karena OP menyebutkan volume "root", itu akan menjadi terlalu besar untuk sebagian besar dari itu agar muat dalam memori. Tapi pasti cache kebetulan berada di jalan saya selama pengujian saya - yang gagal total sampai saya mulai menjatuhkannya. Saya akan memperbarui jawaban saya.
fra-san
2

Apakah SSD memiliki lapisan enkripsi perangkat keras bawaan? Jika ada, maka blok TRIMmed mungkin all-nol (atau mungkin semua-yang) pada tingkat perangkat keras, tetapi karena komputer melihatnya melalui lapisan enkripsi, mereka akan muncul sebagai omong kosong semu acak setelah melewati semua -menggunakan blok mentah melalui proses dekripsi.

Lapisan enkripsi perangkat keras seperti itu akan memiliki beberapa keuntungan:

  • Ini akan memungkinkan fungsionalitas penghapusan keamanan yang sangat cepat: hanya saja drive menghancurkan kunci asli yang digunakan dalam lapisan enkripsi perangkat keras dan menggantinya dengan yang baru dan semua data akan langsung dapat dipulihkan untuk tujuan paling praktis.
  • Karena semua data yang mencapai level perangkat keras mentah akan dienkripsi, itu akan dijamin untuk terlihat pseudo-acak dan dengan demikian sebagian besar homogen. Ini mungkin membantu menghindari titik panas / dingin dan menyederhanakan estimasi keausan.
telcoM
sumber
0

df melaporkan ruang kosong tidak berarti ruang kosong.

trimmemberi tahu perangkat penyimpanan bahwa blok tidak digunakan. Saya tidak berpikir bahwa ini nol mereka.

ctrl-alt-delor
sumber