ตรวจสอบอย่างอิสระว่า TRIM ใช้งานได้จริงบน SSD

ฉันมีLUKSพาร์ติชัน/dev/sda1ที่ฉันรักเปิดด้วย--allow-discards:

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

ฉันเมานext4ระบบไฟล์ด้วยdiscardตัวเลือก:

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

จากนั้นฉันจะตัดพื้นที่ว่างบนพาร์ติชันที่เมาท์:

fstrim -v /

ด้วยdfฉันเห็นว่า/มีพื้นที่ว่าง 80% นั่นหมายความว่าใน/dev/sda180% ของดิสก์เป็นศูนย์เลขฐานสอง

ถ้าฉันโคลนภาพด้วย cat

cat /dev/sda1 > sda1.img

และบีบอัดภาพด้วยxzฉันคาดหวังว่าศูนย์ทั้งหมดบนดิสก์จะถูกบีบอัด เนื่องจากข้อมูล 20% ของดิสก์ถูกเข้ารหัสจึงควรมีลักษณะแบบสุ่มและไม่สามารถบีบอัดได้ ดังนั้นอิมเมจที่ถูกบีบอัด xz ควรเป็น aprox 20% ของขนาดดิบ

อย่างไรก็ตามรูปภาพที่บีบอัด xz ที่ได้นั้นมีขนาดใกล้เคียงกับต้นฉบับดั้งเดิม

เหตุผลของฉันถูกต้องหรือไม่

ทำไมทฤษฎีของฉันไม่แปลสู่การปฏิบัติ

ตรรกะของคุณไม่ถูกต้อง แต่จะใช้ได้ก็ต่อเมื่อเงื่อนไขบางอย่างพอใจ

คำสั่ง TRIMตามที่ระบุไว้ในชุดคำสั่ง ATA , หรืออาจจะไม่เป็นศูนย์ภาคมันจะออกมาต่อต้าน
ที่จริงแล้วมาตรฐานมุ่งเน้นไปที่ข้อมูลที่จะต้องส่งคืนหลังจากออก TRIM ¹ :

พฤติกรรมการติดตามถูกระบุโดยมาตรฐานนี้สำหรับส่วนที่อุปกรณ์ภายนอก (ดู 7.5.3.3):

a) non-deterministic - ข้อมูลในการตอบสนองต่อการอ่านจากเซกเมนต์ที่ถูกตัดทอนอาจเปลี่ยนไปสำหรับการอ่านแต่ละครั้งจนกว่าโฮสต์จะถูกเขียนโดยโฮสต์;
b) กำหนดอ่านหลังจากตัด (DRAT) - ข้อมูลที่ส่งคืนในการตอบสนองต่อการอ่านของเซกเตอร์ตัดแต่งไม่เปลี่ยนแปลง แต่อาจแตกต่างจากข้อมูลที่ถูกส่งคืนก่อนหน้านี้; และ
c) อ่าน Zeroes After Trim (RZAT) - ข้อมูลที่ส่งคืนเพื่อตอบสนองต่อการอ่านของเซกเตอร์ที่ถูกเล็มเป็นศูนย์

[... ] สำหรับอุปกรณ์จัดเก็บข้อมูล DRAT และที่ไม่ได้กำหนดค่าไว้ข้อมูลที่ส่งคืนเพื่อตอบสนองต่อคำสั่ง read ไปยัง LBA ที่ได้รับการตัดแต่งเรียบร้อยแล้ว:

a) อาจเป็นข้อมูลที่ส่งคืนก่อนหน้านี้สำหรับ LBA ที่ระบุ
b) อาจเป็นรูปแบบที่สร้างขึ้นโดยอุปกรณ์เก็บข้อมูล และ
c) ไม่ใช่ข้อมูลที่เขียนก่อนหน้านี้ไปยัง LBA อื่นโดยโฮสต์

ดังนั้นสิ่งที่อุปกรณ์ของคุณจะส่งกลับหลังจากนั้นfstrimขึ้นอยู่กับคุณสมบัติที่ใช้ ยกเว้นว่ารองรับ RZAT ข้อสันนิษฐานว่าข้อมูลที่อ่านจากอุปกรณ์ที่ถูกตัดจะเป็นศูนย์เท่านั้นที่ไม่ได้เก็บไว้

คุณสามารถใช้hdparmเพื่อตรวจสอบสิ่งนี้:

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

ผมดำเนินการทดสอบบางอย่างใช้สอง SSDs, และsda sdbผู้ผลิตรายเดียวกันรุ่นต่าง ๆ ที่มีความแตกต่างของ ATA:

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

SSD สองตัวมีการรองรับ 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

ฉันสามารถยืนยันได้ว่าหลังจากออกfstrimไดรฟ์ที่รองรับ "อ่านค่าเป็นศูนย์หลังจาก TRIM" (RZAT) ดูเหมือนว่าจะมีพาร์ติชันที่เกี่ยวข้องเกือบทั้งหมดเป็นศูนย์ ตรงกันข้ามไดรฟ์อื่นดูเหมือนจะเป็นศูนย์ (หรือแทนที่ด้วยรูปแบบการบีบอัดสูงบางส่วน) เพียงส่วนเล็ก ๆ ของพื้นที่ว่าง

¹ _{แหล่งข้อมูลออนไลน์: INCITS 529: เทคโนโลยีสารสนเทศ - ชุดคำสั่ง ATA / ATAPI - 4 (ACS-4)}

หมายเหตุเกี่ยวกับการทดสอบ:

ตามที่Frostschutzชี้ไว้ในความคิดเห็นการอ่านหลังจากfstrimอาจส่งคืนข้อมูลจากแคชของระบบปฏิบัติการไม่ใช่จากอุปกรณ์ที่ถูกตัด มันเป็นเช่นสิ่งที่เกิดขึ้นในqustion นี้
(ฉันจะชี้ไปที่คำตอบนี้สำหรับคำถามเดียวกันสำหรับวิธีอื่นในการทดสอบ TRIM)

ระหว่างfstrimและหลังจากอ่านคุณอาจต้องวางแคชเช่นด้วย:

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

ขึ้นอยู่กับขนาดของพาร์ติชันที่คุณกำลังเล่นอยู่การไม่วางแคชอาจทำให้การทดสอบของคุณล้มเหลว

หมายเหตุเกี่ยวกับการตั้งค่าของคุณ:

discardตัวเลือกที่ช่วยให้ติด TRIM อย่างต่อเนื่องเช่นไฟล์เวลาใด ๆ จะถูกลบออก fstrimมันเป็นเรื่องที่ไม่จำเป็นต้องตาม แท้จริงแล้ว TRIM แบบออนดีมานด์และ TRIM แบบต่อเนื่องเป็นสองวิธีที่แตกต่างกันในการจัดการการดำเนินงานของ TRIM สำหรับข้อมูลเพิ่มเติมฉันจะชี้ไปที่ไดรฟ์ Solid stateบน Arch Linux Wiki ซึ่งมีรายละเอียดครอบคลุมเรื่องนี้

SSD มีเลเยอร์การเข้ารหัสฮาร์ดแวร์ในตัวหรือไม่? หากมีหนึ่งบล็อก TRIMmed อาจเป็นศูนย์ทั้งหมด (หรืออาจเป็นทั้งหมดก็ได้) ที่ระดับฮาร์ดแวร์ดิบ แต่เนื่องจากคอมพิวเตอร์เห็นพวกเขาผ่านชั้นการเข้ารหัสพวกเขาจะปรากฏเป็นความหมายแบบสุ่มหลอกผ่านหลังจากทั้งหมด - บล็อกดิบผ่านกระบวนการถอดรหัส

เลเยอร์การเข้ารหัสฮาร์ดแวร์ดังกล่าวจะมีข้อได้เปรียบบางอย่าง:

• มันจะทำให้ฟังก์ชั่นการลบความปลอดภัยรวดเร็วมาก: เพียงแค่ให้ไดรฟ์ทำลายคีย์ดั้งเดิมที่ใช้ในเลเยอร์การเข้ารหัสฮาร์ดแวร์และแทนที่ด้วยคีย์ใหม่และข้อมูลทั้งหมดจะไม่สามารถกู้คืนได้ทันทีเพื่อการใช้งานจริงมากที่สุด
• เนื่องจากข้อมูลทั้งหมดที่ถูกเข้ารหัสในระดับฮาร์ดแวร์ดิบจะถูกเข้ารหัสจึงรับประกันได้ว่าจะมีการสุ่มหลอกและทำให้เหมือนกันมาก สิ่งนี้อาจช่วยหลีกเลี่ยงจุดร้อน / เย็นและทำให้การประเมินการสึกหรอง่ายขึ้นมาก

การละทิ้งไม่เหมือนกับ Zero

หากคุณต้องการเป็นศูนย์ด้วย cryptsetup คุณสามารถย่อขนาด fs ได้จากนั้น crypt block จะทำการ dd พื้นที่ว่างที่ไม่ได้ใช้

หากคุณต้องการทราบว่าการตัดแต่งทำงานได้หรือไม่การทดสอบความเร็วควรเป็นตัวบ่งชี้หลังจากการใช้งานหนัก

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

df การรายงานพื้นที่ว่างไม่ได้บ่งบอกถึงพื้นที่ว่างเป็นศูนย์

trimบอกอุปกรณ์เก็บข้อมูลว่าไม่ได้ใช้บล็อก ฉันไม่คิดว่าเลขศูนย์พวกนี้