TRIM'in gerçekten SSD üzerinde çalıştığını bağımsız olarak doğrulayın

Ben luksOpen olan bir LUKSbölüm var :/dev/sda1--allow-discards

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

Sonra ext4dosya sistemi discardseçeneği ile monte :

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

Daha sonra monte edilen bölümdeki boş alanı düzeltirim:

fstrim -v /

ile dfAnlıyorum, /% 80 boş alan vardır. Bu /dev/sda1, diskin% 80'inin ikili sıfır olduğu anlamına gelir .

Eğer görüntüyü klonlarsam cat

cat /dev/sda1 > sda1.img

ve görüntüyü sıkıştırmak için xz, diskteki tüm sıfırların sıkıştırılmasını beklerdim. Diskteki verilerin% 20'si şifreli olduğu için rastgele görünmeli ve sıkıştırılamaz olmalıdır. Bu nedenle, xz sıkıştırılmış görüntü yaklaşık olmalıdır. Ham boyutun% 20'si.

Ancak, sonuçta elde edilen xz sıkıştırılmış görüntü, ham orijinal ile yaklaşık aynı boyuttadır.

Akıl yürütmem doğru mu?

Teorim neden uygulamaya dönüşmüyor?

Mantık yanlış değil. Ancak bu, yalnızca bazı koşullar sağlandığında geçerlidir.

TRIM komutu belirtilen, ATA komut seti , ya da karşı verilir sektörleri sıfır olabilir veya olmayabilir.
Aslında, standart TRIM verildikten sonra hangi verilerin iade edilmesi gerektiğine odaklanmaktadır ¹ :

Aşağıdaki davranışlar, aygıtın kırptığı sektörler için bu standart tarafından belirtilir (bkz. 7.5.3.3):

a) deterministik olmayan - kesilmiş bir sektörden gelen bir okumaya yanıt olarak veriler, sektör ev sahibi tarafından yazılana kadar her bir okuma için değişebilir;
b) Kırpmadan Sonra Deterministik Okuma (DRAT) - kesilmiş bir kesimin okunmasına yanıt olarak döndürülen veriler değişmez, ancak daha önce döndürülen verilerden farklı olabilir; ve
c) Kırpmadan Sonra Sıfırları Oku (RZAT) - kırpılan sektörün okunmasına yanıt olarak döndürülen veriler sıfırdır.

[...] Hem DRAT hem de deterministik olmayan depolama aygıtları için, başarıyla kesilmiş bir LBA'ya okuma komutuna yanıt olarak döndürülen veriler:

a) belirtilen LBA için önceden döndürülen veriler olabilir;
b) depolama cihazı tarafından üretilen bir model olabilir; ve
c) ev sahibi tarafından daha önce farklı bir LBA'ya yazılan veriler değildir.

Bu nedenle, cihazınızın sonra ne döndürdüğü fstrimuyguladığı özelliklere bağlıdır. RZAT'ı desteklemediği sürece, kesilmiş bir cihazdan okunan verilerin yalnızca sıfır olacağı varsayımı tutmaz.

Bunu hdparmkontrol etmek için kullanabilirsiniz :

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

İki SSD kullanarak bazı testler yaptım sdave sdb. Aynı üretici, farklı modeller, farklı ATA uyumluluğu ile:

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

İki SSD'nin TRIM için farklı desteği var:

$ 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

Bunu teyit edebilir, vermeden sonra fstrim, destekleyici sürücü (RZAT) "deterministik TRIM sonra sıfırları okumak" aslında neredeyse tamamen ilgili bölüm sıfırlanmasını gibi görünüyor. Tersine, diğer sürücünün boş alanın sadece küçük bir kısmı sıfırlanmış (veya başka bir şekilde oldukça sıkıştırılabilir bir modelle değiştirilmiş) görünmektedir.

¹ _{Çevrimiçi kaynak: INCITS 529: Bilgi teknolojisi - ATA / ATAPI Komut Seti - 4 (ACS-4)}

Test hakkında not:

Yorumlarda frostschutz tarafından işaret edildiği gibi , bir okuma sonrası fstrim, kesilmiş cihazdan değil, işletim sistemi önbelleğinden veri döndürebilir. Örneğin, bu qustion'da olan buydu .
(Ben de işaret ediyorum bu cevap TRIM test etmek için alternatif bir yöntem için aynı soruya).

Arasında fstrimve sonraki okuma arasında önbelleği bırakmanız gerekebilir, örneğin:

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

Oynadığınız bölümün boyutuna bağlı olarak, testlerin başarısız olması için önbelleği düşürmemek yeterli olabilir.

Kurulumunuzla ilgili not:

discardSeçenek her zaman dosyalar silinir yani sürekli TRIM, kolayca monte edin. Tarafından gerekli değildir fstrim. Aslında, isteğe bağlı TRIM ve sürekli TRIM, TRIM operasyonlarını yönetmenin iki ayrı yoludur. Daha fazla bilgi için Arch Linux Wiki'de bu konunun ayrıntılı bir şekilde ele alındığı Katı hal sürücüsüne işaret edeceğim .

SSD'nin yerleşik bir donanım şifreleme katmanı var mı? Bir tane varsa, TRIMmed blokları ham donanım düzeyinde tamamen sıfır olabilir (veya muhtemelen hepsi olabilir), ancak bilgisayar bunları şifreleme katmanından gördüğünden, tümünü geçtikten sonra sahte rasgele anlamsız görünürler. -şifreleme işlemi ile ham blok sıfırlar.

Böyle bir donanım şifreleme katmanının bazı avantajları olacaktır:

• Çok hızlı güvenlik silme işlevselliğine izin verir: sadece sürücünün donanım şifreleme katmanında kullanılan orijinal anahtarı yok etmesini ve yenisiyle değiştirmesini sağlayın ve tüm veriler en pratik amaçlar için anında kurtarılamaz.
• Ham donanım düzeyine isabet eden tüm veriler şifreleneceğinden, sözde rastgele görünmesi ve dolayısıyla büyük ölçüde homojen olması garanti edilecektir. Bu, sıcak / soğuk noktalardan kaçınmaya ve aşınma tahminini basitleştirmeye yardımcı olabilir.

Atma Sıfır ile aynı değildir.

Eğer cryptsetup ile sıfırlamak istiyorsanız fs'yi küçültebilirsiniz, sonra crypt bloğu sonra kullanılmayan hacim alanını dd.

Trimin bir hız testi yaparak çalışıp çalışmadığını bilmek istiyorsanız, yoğun kullanımdan sonra bir gösterge olmalıdır.

https://linux.die.net/man/8/fstrim https://en.m.wikipedia.org/wiki/Trim_(computing)

df boş alan bildirilmesi sıfır alan anlamına gelmez.

trimdepolama cihazına blokların kullanılmadığını bildirir. Bunun sıfır olduğunu sanmıyorum.