SSD पर BtrFS के साथ TRIM समर्थन सत्यापित करें


21

हम SSD डिस्क की एक सरणी पर BtrFS का उपयोग कर रहे हैं और मुझे यह सत्यापित करने के लिए कहा गया है कि BtrFS वास्तव में एक फ़ाइल को हटाने पर TRIM संचालन करता है। अब तक मैं यह सत्यापित करने में असमर्थ रहा हूं कि डिस्क पर TRIM कमांड भेजा गया है।

मुझे पता है कि BtrFS को उत्पादन के लिए तैयार नहीं माना जाता है, लेकिन हमें रक्तस्राव बढ़त पसंद है, इसलिए मैं इसका परीक्षण कर रहा हूं। सर्वर Ubuntu 11.04 सर्वर 64-बिट रिलीज़ (mkfs.btrfs संस्करण 0.19) है। मैंने लिनक्स 3.0.0 कर्नेल को BtrFS चैंज के रूप में स्थापित किया है जो बताता है कि उबंटू 11.04 (2.6.38) के साथ भेजे गए कर्नेल में बल्क टीआरआईएम उपलब्ध नहीं है।

यहाँ मेरी परीक्षण पद्धति (शुरू में http://andyduffell.com/techblog/?p=852 से अपनाया गया , BtrFS के साथ काम करने के लिए संशोधनों के साथ):

  • मैन्युअल रूप से शुरू होने से पहले TRIM डिस्क: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • सत्यापित करें कि ड्राइव TRIM'd था: ./sectors.pl |grep + | tee sectors-$(date +%s)
  • विभाजन ड्राइव: fdisk /dev/sda
  • फ़ाइल सिस्टम बनाएं: mkfs.btrfs /dev/sda1
  • माउंट: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
  • एक फ़ाइल बनाएँ: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
  • सत्यापित करें कि फ़ाइल डिस्क पर है: ./sectors.pl | tee sectors-$(date +%s)
  • परीक्षण फ़ाइल हटाएँ: rm /mnt/testfile
  • देखें कि परीक्षण फ़ाइल डिस्क से TRIM'd है: ./sectors.pl | tee sectors-$(date +%s)
  • TRIM'd ब्लॉक सत्यापित करें: diffदो सबसे हाल की sectors-*फाइलें

इस बिंदु पर, प्री-डिलीट और पोस्ट डिलीट वेरिफिकेशन अभी भी उपयोग में समान डिस्क ब्लॉक दिखाते हैं। मुझे इसके बजाय उपयोग ब्लॉकों की संख्या में कमी देखना चाहिए। परीक्षण फ़ाइल को हटाए जाने के बाद एक घंटे की प्रतीक्षा में (अगर TRIM आदेश जारी होने में कुछ समय लगता है) तब भी उपयोग में समान ब्लॉक दिखाता है।

मैंने -o ssd,discardविकल्पों के साथ बढ़ते रहने की भी कोशिश की है , लेकिन यह बिल्कुल भी मदद नहीं करता है।

विभाजन जो fdiskऊपर से बनाया गया था (मैं विभाजन को छोटा रखता हूं ताकि सत्यापन तेज हो सके):

root@ubuntu:~# fdisk -l -u /dev/sda

Disk /dev/sda: 512.1 GB, 512110190592 bytes
255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6bb7542b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63      546209      273073+  83  Linux

मेरी sectors.plस्क्रिप्ट (मुझे पता है कि यह अक्षम है, लेकिन इससे काम हो जाता है):

#!/usr/bin/perl -w

use strict;

my $device = '/dev/sda';
my $start = 0;
my $limit = 655360;

foreach ($start..$limit) {
    printf "\n%6d ", $_ if !($_ % 50);
    my @sector = `/sbin/hdparm --read-sector $_ $device`;
    my $status = '.';
    foreach my $line (@sector) {
            chomp $line;
            next if $line eq '';
            next if $line =~ /$device/;
            next if $line =~ /^reading sector/;
            if ($line !~ /0000 0000 0000 0000 0000 0000 0000 0000/) {
                    $status = '+';
            }
    }
    print $status;
}
print "\n";

क्या मेरी परीक्षण पद्धति त्रुटिपूर्ण है? क्या मुझसे कोई चूक हो रही है?

सहायता के लिए धन्यवाद।


1
मैं पूरी तरह से ब्लीडिंग एज चीजों का परीक्षण करने का समर्थन करता हूं, लेकिन अभी आप जानते हैं, अभी के अनुसार, btrfs के पास fsck नहीं है जो वास्तव में, आप जानते हैं, चीजों को ठीक करता है: btrfs.wiki.kernel.org/index.php/My_Page - तो बस उसके लिए बाहर देखो।
मैट सीमन्स

@ मट - गुम fsck के बारे में अच्छी बात है। मेरी समझ यह है कि फस्क का पहला संस्करण अगले कुछ हफ्तों के भीतर जहाज जाना चाहिए, इसलिए हमें उस समय तक कवर किया जाना चाहिए जब हम इसे उत्पादन के लिए स्थानांतरित करते हैं। इसके अतिरिक्त, हमारे पास हमारे डेटा की कई प्रतियां होंगी, इसलिए यदि हम एक कॉपी को ढीला करते हैं, तो हमारे पास कम से कम दो और प्रतियां हैं, जिनसे हम पुनर्स्थापित हो सकते हैं। लेकिन मैं इस बात से पूरी तरह सहमत हूं कि यह अब के लिए अपूरणीय डेटा वाले लोगों के लिए फ़ाइल सिस्टम नहीं है।
शेन मेयर्स

1
शायद कुछ भी नहीं बदलेगा, लेकिन आप syncफ़ाइल को rmming के बाद चलाने की कोशिश कर सकते हैं ।
zebediah49

मैं कहना चाहता हूं कि मैंने syncफाइल निकालने के बाद दौड़ने की कोशिश की और परिणाम अभी भी वही हैं। मैं दोबारा जांच करूंगा कि हालांकि सप्ताहांत खत्म होने के बाद जब मैं कार्यालय में वापस आऊंगा।
शेन मेयर्स

अगर आपको ब्लीडिंग एज से कोई आपत्ति नहीं है, तो क्या आपने zfsonlinux.org पर विचार किया है ? मूल (कर्नेल में, फ्यूज नहीं) लिनक्स के लिए ZFS। वे एक आधिकारिक "रिलीज़" के करीब हैं, और आरसी उपलब्ध हैं (उबंटू के लिए एक पीपीए सहित - डेबियन के लिए पुनर्निर्माण के लिए काफी आसान)
कैस

जवाबों:


4

इसलिए कई दिनों तक इस पर काम करने के बाद, मैं यह प्रदर्शित करने में सक्षम था कि BtrFS TRIM का उपयोग करता है। मैं सर्वर पर सफलतापूर्वक TRIM काम करने में असमर्थ था कि हम इन SSDs को तैनात करेंगे। हालांकि, जब एक ही ड्राइव का उपयोग करके परीक्षण लैपटॉप में प्लग किया जाता है, तो परीक्षण सफल होते हैं।

इस परीक्षण के लिए प्रयुक्त हार्डवेयर:

  • Crucial m4 SSD 512GB
  • एचपी DL160se G6
  • LSI LSISAS9200-8e HBA
  • सामान्य SAS संलग्नक
  • डेल XPS m1210 लैपटॉप

सर्वर पर BtrFS को सत्यापित करने में कई असफल प्रयासों के बाद, मैंने पुराने लैपटॉप का उपयोग करके इसी परीक्षण की कोशिश करने का फैसला किया (RAID कार्ड परत को हटा दें)। लैपटॉप पर Ext4 और BtrFS दोनों का उपयोग करके इस परीक्षण के प्रारंभिक प्रयास विफल हो जाते हैं (डेटा TRIM'd नहीं)।

फिर मैंने संस्करण 0001 से (संस्करण को बॉक्स से बाहर भेज दिया गया) के रूप में संस्करण 0009 में एसएसडी ड्राइव फर्मवेयर को अपग्रेड किया। एक्स्ट 4 और बीआरटीएफएस के साथ परीक्षण दोहराया गया और दोनों फाइल सिस्टम ने डेटा को सफलतापूर्वक ट्रिम किया।

TRIM कमांड को चलाने का समय सुनिश्चित करने के लिए, मैंने rm /mnt/testfile && sync && sleep 120सत्यापन करने से पहले किया था ।

एक बात ध्यान दें कि यदि आप एक ही परीक्षण का प्रयास कर रहे हैं: SSDs ने उन ब्लॉकों को मिटा दिया है जो वे संचालित करते हैं (मुझे क्रूसिबल एम 4 मिटा ब्लॉक का आकार नहीं पता है)। जब फ़ाइल सिस्टम ड्राइव पर TRIM कमांड भेजता है, तो ड्राइव केवल एक पूर्ण ब्लॉक मिटा देगा; यदि TRIM कमांड एक ब्लॉक के एक हिस्से के लिए निर्दिष्ट किया गया है, तो ब्लॉक ब्लॉक के भीतर शेष वैध डेटा के कारण TRIM'd नहीं होगा।

तो यह दिखाने के लिए कि मैं किस बारे में बात कर रहा हूं ( sectors.plऊपर की स्क्रिप्ट का आउटपुट )। यह एसएसडी पर परीक्षण फ़ाइल के साथ है। पीरियड्स ऐसे सेक्टर हैं जिनमें केवल शून्य होते हैं। प्लसस में एक या अधिक गैर-शून्य बाइट्स होते हैं।

ड्राइव पर परीक्षण फ़ाइल:

24600 .......................................+++++++++++
24650 ++++++++++++++++++++++++++++++++++++++++++++++++++
24700 ++++++++++++++++++++++++++++++++++++++++++++++++++
    -- cut --
34750 ++++++++++++++++++++++++++++++++++++++++++++++++++
34800 ++++++++++++++++++++++++++++++++++++++++++++++++++
34850 +++++++++++++++++++++++++++++.....................

टेस्ट फाइल ड्राइव से हटाई गई (a sync && sleep 120) के बाद :

24600 .......................................+..........
24650 ..................................................
24700 ..................................................
    -- cut --
34750 ..................................................
34800 ..................................................
34850 ......................+++++++.....................

ऐसा प्रतीत होता है कि फ़ाइल का पहला और अंतिम सेक्टर बाकी फाइल से अलग मिटा ब्लॉक में हैं। इसलिए कुछ क्षेत्रों को अछूता छोड़ दिया गया था।

एक takeaway फॉर्म यह है: कुछ Ext4 TRIM परीक्षण निर्देश उपयोगकर्ता को केवल यह सत्यापित करने के लिए कहते हैं कि पहला क्षेत्र फ़ाइल से TRIM'd था। परीक्षक को परीक्षण फ़ाइल का एक बड़ा हिस्सा वास्तव में यह देखने के लिए देखना चाहिए कि क्या TRIM सफल था या नहीं।

अब यह जानने के लिए कि RAID कार्ड काम के माध्यम से SSD को मैन्युअल रूप से भेजे गए TRIM कमांड क्यों जारी किए जाते हैं, लेकिन स्वचालित TRIM कमांड नहीं ...


मैंने सोचा कि सभी HW RAID ने ट्रिम कमांड खा लिए, यह देखकर अच्छा लगा कि चीजें धीरे-धीरे बदल रही हैं। दूसरी ओर, अच्छी आधुनिक ड्राइव के साथ, TRIM कम और कम मायने रखती है।
रोनाल्ड पोटोल

4

मैंने जो पढ़ा है, उसके आधार पर आपकी कार्यप्रणाली में दोष हो सकता है।

आप मान रहे हैं कि TRIM आपके SSD को उन ब्लॉकों को शून्य कर देगा, जिन्हें हटा दिया गया है। हालाँकि अक्सर ऐसा नहीं होता है।

यदि SSD TRIM को लागू करता है तो केवल इसलिए कि यह छूट गए ब्लॉकों को शून्य करता है। आप यह जांच सकते हैं कि डिवाइस को त्यागने के लिए पर्याप्त रूप से पता है कि_रिट्स_डेटा रिपोर्ट करें:

cat / sys / block / sda / que / / त्याग_श्रेता_दता

इसके अलावा, यहां तक ​​कि अगर SSD शून्य करता है, तो कुछ समय लग सकता है - अच्छी तरह से हार पूरी होने के बाद - SSD के लिए वास्तव में ब्लॉकों को शून्य करना (यह कुछ कम गुणवत्ता वाले SSDs का सच है)।

http://www.redhat.com/archives/linux-lvm/2011-April/msg00048.html

BTW मैं TRIM को सत्यापित करने के लिए एक विश्वसनीय तरीका ढूंढ रहा था और अभी तक नहीं मिला है। अगर किसी को रास्ता मिल जाए तो मुझे अच्छा लगेगा।


3

यहाँ 10.10 और EXT4 के लिए परीक्षण पद्धति है। शायद यह मदद करेगा।

/ubuntu/18903/how-to-enable-trim

ओह, और मुझे लगता है कि आपको fstab माउंट पर त्यागने वाले पैरामीटर की आवश्यकता है। यकीन नहीं होता कि SSD परम की जरूरत है क्योंकि मुझे लगता है कि SSD का ऑटो पता लगाना चाहिए।


2
मैंने Ext4 SSD सत्यापन निर्देशों का पालन करने का प्रयास किया है, लेकिन वे अन्य फ़ाइल सिस्टम की तुलना में BtrFS के काम करने के तरीके के अंतर के कारण काम नहीं करते हैं। इसलिए वर्कफ़्लो मैं साथ आया था। मैंने ssdयह सुनिश्चित करने के लिए माउंट विकल्प का उपयोग किया कि BtrFS अपने SSD- विशिष्ट कोड का उपयोग करना जानता था, भले ही उसे ऑटो पता होना चाहिए। मैंने भी उपयोग करने की कोशिश की discard(जैसा कि ऊपर उल्लेख किया गया है) और इससे मदद नहीं मिली।
शेन मेयर्स

ओह अच्छा। एक शॉट के लायक :)
डेव वफ़र

1

discardTRIM समर्थन को सक्षम करने के लिए आपको btrfs के लिए विकल्प की आवश्यकता होती है।

कार्यात्मक TRIM के लिए एक बहुत ही सरल लेकिन काम करने वाला परीक्षण यहां है: http://techgage.com/article/enabled_and_testing_ssd_trim_support_under_linux/2


1
जैसा कि मैंने ऊपर उल्लेख किया है, मैंने discardविकल्प और विकल्प दोनों के साथ अपने परीक्षण की कोशिश की ssd। BtrFS डॉक्स ने ssdविकल्प का बहुत उल्लेख किया है , इसलिए मैंने अपने परीक्षण पर ध्यान केंद्रित किया, लेकिन न तो विकल्प के परिणामस्वरूप मुझे उम्मीद थी। अधिकांश वेबपेज जो दिखाते हैं कि TRIM का परीक्षण कैसे किया जाता है, एक्सट्रीम 4 और लाइक के लिए हैं। BtrFS को फ़ाइल सिस्टम के डिज़ाइन में अंतर के कारण उन कार्यप्रणालियों का उपयोग करके परीक्षण नहीं किया जा सकता है।
शेन मेयर्स

hdparm --fibmapएफएस अज्ञेयवादी है। दिए गए LBA पते पर एक ब्लॉक या तो शून्य है, या नहीं, यह extN, btrfs, xfs, jfs ... ssdविकल्प ट्रिम के लिए अप्रासंगिक है, उदाहरण के लिए btrfs मेलिंग सूची पर यह चर्चा देखें: mail-archive-linux- btrfs @ vger.kernel.org / msg10932.html
पावेल ब्रोडाकी

मैं का उपयोग करने की कोशिश की, hdparm --fibmapलेकिन यह BtrFS पर काम नहीं करता है। यदि आप wiper.sh README (hdparm के साथ वितरित) को देखते हैं, तो वे स्पष्ट रूप से बताते हैं कि "FIEMAP / FIBMAP ioctl () कॉल btrfs फाइल सिस्टम पर उपयोग किए जाने पर पूरी तरह से असुरक्षित हैं।" तो HDParm बाहर है, जो बहुत बुरा है क्योंकि इससे परीक्षण बहुत आसान हो जाएगा। मुझे नहीं पता था कि ssdविकल्प का TRIM से कोई लेना-देना नहीं है क्योंकि डॉक्स विकल्प की उपयोगिता पर बहुत स्पष्ट नहीं हैं।
शेन मेयर्स

Ioctls के बारे में अतिरिक्त जानकारी के लिए धन्यवाद, मुझे यह नहीं पता था। मुझे लगता है कि अतिरिक्त जानकारी के लिए पूछने के लिए सबसे अच्छी जगह btrfs मेलिंग सूची हो सकती है। आपको वहां से फर्स्ट-हैंड जानकारी मिलेगी।
पवेल ब्रोडाकी

1

सोचने के लिए कुछ बातें (उत्तर देने के लिए अपने "क्या मुझे कुछ याद आ रहा है?" प्रश्न):

  • वास्तव में क्या है / देव / sda? एक एसएसडी या (हार्डवेयर?) SSDs की RAID सरणी?

  • अगर बाद तो RAID नियंत्रक किस तरह का?

  • और क्या आपका RAID नियंत्रक TRIM का समर्थन करता है?

और अंत में,

  • क्या आपके परीक्षण का तरीका आपको वे परिणाम देता है जो आप अपेक्षा करते हैं यदि आप btrfs के अलावा किसी अन्य चीज़ के साथ प्रारूपित / dev / sda1 हैं?

1

वस्तुतः सभी एसएसडी एक SATA इंटरफ़ेस के साथ कुछ प्रकार की लॉग संरचना फाइलसिस्टम चलाते हैं जो आपसे पूरी तरह से छिपा हुआ है। SATA 'ट्रिम' कमांड डिवाइस को बताता है कि ब्लॉक अब उपयोग में नहीं है और अंतर्निहित लॉग स्ट्रक्चर फाइलसिस्टम इसे फ्लैश कर सकता है / अगर / इसी इरेज ब्लॉक (जो काफी बड़ा हो सकता है) / केवल / ट्रिम के साथ चिह्नित ब्लॉक शामिल हैं।

मैंने मानक डॉक्स नहीं पढ़े हैं, जो यहां हैं: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim , लेकिन मुझे यकीन नहीं है कि कोई मानक स्तर की गारंटी है जो आप कर पाएंगे ट्रिम कमांड के परिणाम देखें। यदि आप कुछ परिवर्तन देख सकते हैं, जैसे कि पहले कुछ बाइट एक मिटा ब्लॉक की शुरुआत में शून्य से बाहर हो जाते हैं, तो मुझे नहीं लगता कि कोई भी ग्वारेंटी यह विभिन्न उपकरणों या शायद फर्मवेयर संस्करण में भी लागू है।

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

शायद SSDs फ्लैश ट्रांसलेशन लेयर से संबंधित मेटाडेटा लाने के लिए SATA कमांड (OEM कमांड?) है?

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.