स्वतंत्र रूप से सत्यापित करें कि TRIM वास्तव में SSD पर काम करता है

13

मेरे पास एक LUKSविभाजन है /dev/sda1जिसके साथ मैं luksOpen करता हूं --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- संपीड़ित छवि कच्चे मूल के समान आकार की होती है।

क्या मेरा तर्क सही है?

मेरा सिद्धांत व्यवहार में क्यों नहीं आता?

— मार्टिन वेग्टर
स्रोत

2

unix.stackexchange.com/a/85880/30851 और भीdmsetup table | grep allow_discards

— frostschutz

8

आपका तर्क गलत नहीं है। लेकिन यह केवल तभी मान्य है जब कुछ शर्तें पूरी हों।

TRIM आदेश , के रूप में विनिर्दिष्ट एटीए आदेश सेट , या क्षेत्रों इसके खिलाफ जारी किया जाता है शून्य नहीं हो सकता है।
वास्तव में, कौन-सा डेटा पर मानक केंद्रित के बाद TRIM जारी किया गया है लौटे हो गया है ¹ :

निम्न व्यवहार इस मानक द्वारा निर्दिष्ट किए जाते हैं कि उपकरण ट्रिम होते हैं (देखें 7.5.3.3):

क) गैर-नियतात्मक - एक छंटनी क्षेत्र से पढ़ने के जवाब में डेटा प्रत्येक पढ़ने के लिए बदल सकता है जब तक कि मेजबान द्वारा लिखित क्षेत्र नहीं लिखा जाता है;
बी) ट्रिम (डीआरएटी) के बाद नियतात्मक पढ़ें - छंटनी वाले क्षेत्र के एक पढ़ने के जवाब में लौटाया गया डेटा नहीं बदलता है, लेकिन पहले से लौटाए गए डेटा से अलग हो सकता है; और
ग) ट्रिम (RZAT) के बाद जीरो पढ़ें - छंटनी किए गए क्षेत्र के एक पढ़ने के जवाब में लौटा डेटा शून्य है।

[...] दोनों डीआरएटी और गैर-नियतात्मक भंडारण उपकरणों के लिए, डेटा एक एलबीए को पढ़ी गई कमांड के जवाब में लौटा है जिसे सफलतापूर्वक ट्रिम किया गया है:

क) निर्दिष्ट एलबीए के लिए पहले लौटा डेटा हो सकता है;
बी) भंडारण उपकरण द्वारा उत्पन्न एक पैटर्न हो सकता है; और
सी) पहले से मेजबान द्वारा एक अलग एलबीए को लिखे गए डेटा नहीं है।

इस प्रकार, आपके डिवाइस के बाद जो वापसी fstrimकरता है वह उन सुविधाओं पर निर्भर करता है जो इसे लागू करता है। जब तक यह RZAT का समर्थन नहीं करता है, एक छंटनी डिवाइस से पढ़ा जाने वाला डेटा केवल शून्य नहीं होगा, यह धारणा।

आप इसके hdparmलिए जाँच कर सकते हैं :

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

मैंने दो एसएसडी का उपयोग करके कुछ परीक्षण किए, sdaऔर sdb। एक ही निर्माता, विभिन्न मॉडल, अलग एटीए अनुरूपता के साथ:

$ 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)}

परीक्षण पर ध्यान दें:

जैसा कि टिप्पणियों में फ्रॉस्ट्सचुट्ज़ द्वारा बताया गया है , एक पढ़ने के बाद fstrimऑपरेटिंग सिस्टम कैश से डेटा वापस आ सकता है, और छंटनी की गई डिवाइस से नहीं। मिसाल के तौर पर, इस तबाही में क्या हुआ ।
(मैं TRIM परीक्षण के लिए एक वैकल्पिक विधि के लिए इसी प्रश्न का उत्तर भी दूंगा )।

fstrimबाद में पढ़ने के बीच आपको कैश गिराने की आवश्यकता हो सकती है, जैसे:

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

आपके द्वारा चलाए जा रहे विभाजन के आकार के आधार पर, कैश को न गिराना आपके परीक्षणों के विफल होने के लिए पर्याप्त हो सकता है।

अपने सेटअप पर ध्यान दें:

discardमाउंट विकल्प निरंतर TRIM, यानी किसी भी समय फ़ाइलें नष्ट हो जाती हैं सक्षम बनाता है। इसकी आवश्यकता नहीं है fstrim। वास्तव में, ऑन-डिमांड टीआरआईएम और निरंतर टीआरआईएम टीआरआईएम संचालन के लिए दो अलग-अलग तरीके हैं। अधिक जानकारी के लिए मैं आर्क लिनक्स विकी पर सॉलिड स्टेट ड्राइव की ओर इशारा करता हूं , जिसमें इस मामले की विस्तृत कवरेज है।

— FRA-सान
स्रोत

टीआरआईएम के बाद भी लिनक्स अपने कैश से गैर-शून्य डेटा लौटा सकता है, भले ही एसएसडी इसे जीरो के रूप में फिर से पढ़ेगा। यह वहाँ पर मेरी हाँ-ट्रिम-परीक्षण के साथ एक समस्या थी unix.stackexchange.com/a/85880/30851 लेकिन यह भी पहले और ट्रिम के बाद कच्चे डेटा पढ़ने से संबंधित हो सकता है। इसलिए अगर आपको उम्मीद के मुताबिक शून्य नहीं मिलता है, तो सिर्फ मामले में कैश छोड़ें।

— 14

@frostschutz अच्छा बिंदु! मैं किसी तरह यह मान रहा था कि, चूंकि ओपी ने "रूट" वॉल्यूम का उल्लेख किया है, इसलिए यह स्मृति में फिट होने के लिए इसके एक महत्वपूर्ण हिस्से के लिए बहुत बड़ा होगा। लेकिन निश्चित रूप से कैश मेरे परीक्षणों के दौरान मेरे रास्ते में हुआ - जो बुरी तरह से विफल रहा जब तक मैंने इसे छोड़ना शुरू नहीं किया। मैं अपना जवाब अपडेट करूंगा।

— फ्रा-सान

2

क्या SSD में एक अंतर्निहित हार्डवेयर एन्क्रिप्शन परत है? यदि इसके पास एक है, तो कच्चे हार्डवेयर स्तर पर TRIMmed ब्लॉक ऑल-जीरो (या संभवतः सभी) हो सकते हैं, लेकिन चूंकि कंप्यूटर उन्हें एन्क्रिप्शन परत के माध्यम से देखता है, वे सभी पास से छद्म यादृच्छिक गिबरिश के रूप में दिखाई देंगे डिक्रिप्शन प्रक्रिया के माध्यम से कच्चे ब्लॉक -zeroes।

इस तरह के हार्डवेयर एन्क्रिप्शन लेयर के कुछ फायदे होंगे:

यह बहुत तेज़ी से सुरक्षा की कार्यक्षमता को समाप्त करने की अनुमति देगा: बस ड्राइव को हार्डवेयर एन्क्रिप्शन परत में उपयोग की जाने वाली मूल कुंजी को नष्ट कर दें और इसे एक नए के साथ बदलें और अधिकांश व्यावहारिक उद्देश्यों के लिए सभी डेटा तुरन्त अप्राप्य होंगे।
जैसा कि कच्चे हार्डवेयर स्तर को मारने वाले सभी डेटा को एन्क्रिप्ट किया जाएगा, यह छद्म यादृच्छिक देखने की गारंटी होगी और इस तरह काफी हद तक समरूप होगी। इससे गर्म / ठंडे स्थानों से बचने और पहनने के अनुमान को सरल बनाने में मदद मिल सकती है।

— Telcom
स्रोत

0

त्याग शून्य के समान नहीं है।

यदि आप cryptsetup के साथ शून्य करना चाहते हैं, तो आप fs को सिकोड़ सकते हैं, फिर क्रिप्ट ब्लॉक को अप्रयुक्त वॉल्यूम स्थान को dd कर सकते हैं।

यदि आप जानना चाहते हैं कि क्या ट्रिम ने गति परीक्षण किया तो भारी उपयोग के बाद एक संकेतक होना चाहिए।

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

— user1133275
स्रोत

0

df मुक्त स्थान की रिपोर्टिंग शून्य स्थान का अर्थ नहीं है।

trimस्टोरेज डिवाइस को बताता है कि ब्लॉक का उपयोग नहीं किया गया है। मुझे नहीं लगता कि यह उनके लिए शून्य है।

— Ctrl-Alt-delor
स्रोत