क्या यह शून्य के साथ एक सुधारित ड्राइव को भरने के लिए लेखन प्रदर्शन में सुधार करेगा?


14

मेरे पास 2 टीबी ड्राइव है जो कि> 99% से भरा गया था। मैंने विभाजन को हटा दिया है fidskऔर उनके साथ स्वरूपित किया है mkfs.ext4

जहां तक ​​मुझे पता है, ड्राइव पर जो वास्तविक डेटा था वह अभी भी मौजूद है। फिर भी विभाजन तालिका को पुन: सौंप दिया गया।

सवाल यह है कि क्या डिस्क को साफ करने के बाद आगे की कार्रवाई के लिए लेखन प्रदर्शन में सुधार होगा ? साफ के साथ मेरा मतलब है कि डिस्क को शून्य से भरें?

कुछ इस तरह

dd if=/dev/zero of=/dev/sdx bs=1 count=4503599627370496

8
शून्य के साथ शुरू होने का कोई फायदा नहीं क्योंकि यह किसी भी चीज को अधिलेखित कर देगा जो इसके साथ शुरू होगा।
मोआब

7
यदि यह एक SSD था, तो उत्तर "नर्क नं" होगा, क्योंकि mkfs.ext4 वास्तव में TRIM का उपयोग पूरे विभाजन की सामग्री को छोड़ने के लिए करता है, इसलिए मैन्युअल रूप से शीर्ष पर शून्य लिखने से प्रदर्शन थोड़ा कम हो जाएगा ।
user1686

2
@ मुझे लगता है कि अगर कोई SSD है जो स्वचालित रूप से TRIM के बजाय सभी शून्य के लेखन में बदल जाता है सोच रहा था।
कास्परड

@kasperd: अच्छा अनुवर्ती प्रश्न!
लियोरी

एक अन्य संभावित अनुवर्ती प्रश्न: अगर कहा गया था कि एक VM एक VM पर लगा हुआ था, जो निम्न स्तर की डिस्क अपक्षय करता था, तो क्या वह मदद कर सकता था (यदि वह डेटा जो VM स्तर पर हटा दिया गया था, जब तक कि सिस्टम कुछ VM- जागरूक API का उपयोग नहीं कर रहा है , यह सैन करने के लिए देखना होगा उन सभी को नष्ट कर दिया है कि जबकि उन सब को शून्य करने के लिए स्थापित करने के लिए एक सब शून्य बात करने के लिए सभी उठाई डुप्लिकेट किए गए ब्लॉकों का समूह) के साथ खत्म हो जाएगा ब्लॉक, पर रुकने की जरूरत है
टेलीफोन

जवाबों:


36

नहीं, यह प्रदर्शन में सुधार नहीं करेगा।

टीएल; डीआर: घूर्णी चुंबकीय हार्ड डिस्क ड्राइव उस तरह से काम नहीं करते हैं।

सबसे पहले, जब आप किसी दिए गए डेटा को एक घूर्णी चुंबकीय-भंडारण ड्राइव पर लिखते हैं, तो वह डेटा चुंबकीय डोमेन में बदल जाता है जो वास्तव में आपके द्वारा लिखे गए बिट पैटर्न से बहुत अलग दिख सकता है। यह आंशिक रूप से किया जाता है क्योंकि सिंक्रनाइज़ेशन को बनाए रखना बहुत आसान है जब पैटर्न को प्लाटर से वापस पढ़ा जाता है एक निश्चित मात्रा में परिवर्तनशीलता होती है, और उदाहरण के लिए "शून्य" या "एक" मूल्यों की एक लंबी स्ट्रिंग सिंक्रनाइज़ेशन को बनाए रखने के लिए बहुत कठिन बना देती है। । (क्या आपने 26,393 बिट्स या 26,394 बिट्स पढ़े हैं? आप बिट्स के बीच की सीमा को कैसे पहचानते हैं?) कंप्यूटर डेटा बिट्स और स्टिक चंक्स के बीच इस परिवर्तन को करने की तकनीक समय के साथ विकसित हुई है; उदाहरण के लिए, संशोधित फ्रीक्वेंसी मॉड्यूलेशन , MMFM, देखेंसमूह कोड रिकॉर्डिंग और रन-लंबाई सीमित एन्कोडिंग की अधिक सामान्य तकनीक ।

जैसे वास्तविक रिकॉर्डिंग प्रक्रिया, Hamr , PMR , shingled में है कि वे कैसे चुंबकीय डोमेन शारीरिक मीडिया पर जमा हो जाती है के यांत्रिकी का वर्णन और इतने पर यह करने के लिए orthgonal हैं।

दूसरा, जब आप किसी क्षेत्र में नया डेटा लिखते हैं, तो प्‍लेटर के संबंधित भागों के चुंबकीय डोमेन केवल वांछित मान पर सेट होते हैं। यह उस विशेष भौतिक स्थान पर पिछले चुंबकीय डोमेन की परवाह किए बिना किया गया है। लिखने वाले के सिर के नीचे पहले से ही कताई घूम रही है; पहले वर्तमान मान को पढ़ना, फिर नया मान लिखना यदि और केवल अगर यह अलग है, तो प्रत्येक लिखने के लिए दो क्रांतियों (या प्रत्येक प्लैटर के लिए एक अतिरिक्त सिर) की आवश्यकता होगी, जिससे लेखन विलंबता को दोगुना या ड्राइव की जटिलता को बढ़ा सकता है, बदले में बढ़ती लागत। चूंकि हार्ड डिस्क अनुक्रमिक I / O प्रदर्शन में सीमित कारक है कि रीड / राइट हेड के तहत प्रत्येक बिट कितनी जल्दी गुजरता है, इसलिए यह उपयोगकर्ता को कोई लाभ भी नहीं देगा। (स्वगत कथन के रूप में, यादृच्छिक I / O प्रदर्शन में सीमित कारक कितना तेजी से पढ़ा / लिखा सिर वांछित सिलेंडर पर तैनात किया जा सकता है और फिर वांछित क्षेत्र सिर के नीचे आता है। SSDs यादृच्छिक I / O वर्कलोड में इतना तेज़ हो सकता है कि वह इन दोनों कारकों को पूरी तरह से खत्म कर दे।)

जैसा कि जेकगॉल्ड द्वारा बताया गया है , एक कारण है कि आप कुछ निश्चित पैटर्न (जैसे कि सभी शून्य) के साथ ड्राइव को ओवरराइट करना चाहते हैं, यह सुनिश्चित करना होगा कि पहले से संग्रहीत डेटा के कोई अवशेष बरामद नहीं किए जा सकते हैं , या तो जानबूझकर या गलती से। लेकिन ऐसा करने से ऊपर बताए गए कारणों से ड्राइव के प्रदर्शन पर कोई प्रभाव नहीं पड़ेगा। एक अन्य कारण, जिसे गर्भनिरोधक के रूप में "प्रदर्शन में सुधार" कहा जा सकता है, जैसा कि लियोरी द्वारा बताया गया है , संग्रहीत डिस्क छवियों के अप्रयुक्त भागों के संपीड़न में मदद करना है, लेकिन यहां तक ​​कि उपयोग में सिस्टम के प्रदर्शन में सुधार नहीं करता है।


3
विभाजन / ड्राइव को शून्य करने का एक अन्य कारण यह है कि यदि आप कच्चे विभाजन / ड्राइव डंप (जैसे कि बैकअप के रूप में, मल्टीपल मशीनों के लिए OS इमेज बनाते हैं, सिस्टम माइग्रेशन तकनीक आदि के रूप में) लेने की योजना बनाते हैं। शून्य अच्छी तरह से संपीड़ित करता है, जो कि ड्राइव पर जो भी पिछली सामग्री संग्रहीत थी, उससे भिन्न हो सकता है।
लियोरी

@liori अच्छा बिंदु, लेकिन यह एक आम अंत-उपयोगकर्ता परिदृश्य नहीं है, और यह ओपी का वर्णन करने वाले से बहुत दूर है।
बजे एक CVn

तो ऑप्टिकल डिस्क या तो गैर-घूर्णी हैं या चुंबकीय हैं?
मैक्स राइड

4

आप यह कहते हैं:

सवाल यह है कि क्या डिस्क को साफ करने के बाद आगे की कार्रवाई के लिए लेखन प्रदर्शन में सुधार होगा? साफ के साथ मेरा मतलब है कि डिस्क को शून्य से भरें?

100% नहीं। डिस्क पर शून्य लिखने से प्रदर्शन में सुधार नहीं होता है। आप केवल डेटा को नष्ट करने के लिए ऐसा करेंगे। तो यह जानते हुए कि, आप यह कहते हैं:

जहां तक ​​मुझे पता है, ड्राइव पर जो वास्तविक डेटा था वह अभी भी मौजूद है।

तकनीकी रूप से हाँ ... ड्राइव पर पहले मौजूद डेटा अभी भी कुछ मूलभूत स्तर पर ड्राइव पर मौजूद है। उस ने कहा, यह उस रूप में मौजूद नहीं है जो इस बिंदु पर पहुंच या पुनर्प्राप्त करना आसान है, लेकिन यह चिंता का विषय हो सकता है यदि आप वास्तव में किसी के द्वारा समझौता किए जा रहे डेटा से चिंतित हैं, जो डेटा के उन टुकड़ों को पुनर्प्राप्त करने का प्रयास करने के लिए तैयार हैं। बने हुए हैं।

इसलिए यदि सुरक्षा और गोपनीयता एक चिंता का विषय है, तो आप यह सुनिश्चित करने के लिए ड्राइव पर लिखना चाहते हैं कि सभी खाली स्थान वास्तव में मिटा दिए गए हैं। लेकिन सुरक्षा और गोपनीयता ही एकमात्र कारण है जिसके कारण आप कभी भी शून्य स्थान के साथ मुक्त स्थान मिटा सकते हैं क्योंकि ऐसा करने से प्रदर्शन में कभी सुधार नहीं होता है।


क्या उपकरण को चलाने से recover"आसान" के रूप में गिनती नहीं होती है? यह एक पूर्ण ड्राइव पर बहुत सारी और बहुत सारी फ़ाइलों को चालू कर देगा जो अभी-अभी mkfs'd' हुई थी ।
हॉब्स

0

आप सभी को मेरा दो सेंट का उपहार टो मेरा अपना अनुभव है, हाँ यह मदद करता है लेकिन सावधानी के साथ।

मेरे पास बहुत सारे एसएसडी थे और अपने स्वयं के परीक्षणों के आधार पर मैं मास्टर टेबल को फिर से लिखने और विभाजन को हटाने के बजाय मास्टर तालिका को फिर से लिखने से पहले शून्य के साथ पूरा करने के लिए पुन: दावा करता हूं।

बाद में मैं समझाऊंगा कि क्यों, लेकिन कदम पूरे SSD को भरने के लिए ˋdd fill होंगे, bs = 1M का उपयोग करें, bs = 1 की तुलना में बहुत तेज, और इसे खत्म होने तक बनाने के लिए गिनती पैरामीटर को भूल जाएं (यह कोई अधिक स्थान की त्रुटि देगा जब अंत तक पहुँचने के लिए, इस तरह की त्रुटि को देखने के लिए चिंता मत करो, यह दिखाया गया है); पूर्ण रूप से भरे हुए उपयोग के बाद या जो भी आप एक मास्टर टेबल (एमबीआर / जीपीटी / आदि) लिखना चाहते हैं, वह सभी डिस्क को 'ट्रिम' करेगा, फिर वांछित प्रारूप के साथ विभाजन बनाएं, आदि।

इसे शून्य से क्यों भरें? शॉर्ट एवॉयर यह है कि मेरा अनुभव यह है कि जब मैं इसे कुछ एसएसडी के साथ जीरो से भरता हूं, जहां 2-24 अपठनीय ब्लॉक देना तय हो गया है, अब और ब्लॉक नहीं मिलते हैं।

अब पहली बात यह है कि जब मैं एक नया एसएसडी प्राप्त करता हूं, तो इसका उपयोग करने से पहले, इसे शून्य से भर दें, यह सुनिश्चित करने के लिए कि मैं फिर से अपठनीय 1KiB ब्लॉकों की सामान्य यादृच्छिक त्रुटियों से ग्रस्त नहीं होगा।

मेरा अनुभव: पूरे SSD को पढ़ने / परीक्षण करने के लिए सॉफ़्टवेयर का उपयोग करना (यह बताता है कि प्रत्येक 'सेक्टर' को पढ़ने में कितना समय लगता है) मुझे बहुत सारे '512byte secttors' (1KiB ब्लॉक) के जोड़े मिल रहे थे जो अप्रचलित हैं, और उनकी स्थिति बेतरतीब ढंग से परिवर्तन और विफलताओं की संख्या 2 से 24 तक भिन्न होती है, आदि; जीरो के साथ पूरी तरह से भरने के बाद और मास्टर टेबल को फिर से बनाएं (जो कि छंटनी करता है) कोई और अपठनीय क्षेत्र नहीं।

मेरा क्रैश परीक्षण: इस तरह की त्रुटियों से उबरने के लिए शून्य से भरने का इंस्टेंस, मैं एक एसएसडी का उपयोग करने देता हूं, कुछ घंटों के बाद और केवल एक टेराबाइट से कम (120GBB एसएसडी) के साथ इसे गलत तरीके से मरने के बाद, यह किसी को भी अनुमति नहीं देता है अब इसे एक्सेस करने के लिए, मदरबोर्ड बायोस इसे नहीं देख सकता है, इसे एक्सेस करते समय यूएसबी एनक्लोजर जम जाता है, इसलिए न तो विंडोज इसे देखता है, न ही लिनिक्स fdisk इसे देखता है।

यह एक ही समय में खरीदे गए कई SSD के साथ एक 'डाई' परीक्षण था, समान वाले ... सभी मैं शून्य नहीं मर गए थे, बाकी में बहुत सारे ब्लॉक फिर से आ गए हैं, लेकिन बिना किसी अपठनीय त्रुटि के।

बेशक, मेरा निष्कर्ष यह है कि सभी एसएसडी विश्वसनीय नहीं हैं, चाहे कोई भी ब्रांड और क्षमता हो।

तो उनके साथ पहली बात, मेरे अनुभव में, उन्हें कम से कम एक बार पूरा भरने के लिए मजबूर करना है, यादृच्छिक के साथ शून्य की तुलना में बेहतर है (यह तेज है)।

अधिक, ज्यादातर एसएसडी आंतरिक ट्रिम करते हैं जब शून्य (गार्ब रिकॉलिनेशन एल्गोरिदम, आदि) के साथ लिखा जाता है।

इसके अलावा, यदि आप पहली बार उन्हें एक बार भरते हैं, तो कोई भी ब्लॉक जो लिखने में त्रुटि देता है, वह पुनः प्राप्त हो जाता है। यह बहुत बेहतर है कि इस तरह की चीज बिना किसी महत्वपूर्ण डेटा के साथ होती है, जब लिखित शून्य यदि डेटा खो गया (सभी शून्य था) तो यह प्रासंगिक नहीं है, लेकिन यदि ऑपरेटिंग सिस्टम के लिए डेटा 'महत्वपूर्ण' है तो यह बहुत बुरा है।

अधिकांश SSD रियुलेटोकेट ऐसा करते हैं, लेकिन ब्लॉक पर मौजूद डेटा को खो देते हैं जो लिखने में त्रुटि देते हैं, केवल 'एंटरप्राइज' (वे लागत> 10 € प्रति GiB) सही तरीके से री-राइट करने के बाद राइट री-ट्राई करते हैं। कुछ SSD इस तरह के असफल ब्लॉक पर अन्य सभी 'सेक्टर' को भी ढीला कर देंगे (जैसे कि एक 'त्याग' करना)।

तो सबसे अच्छा, इसे पहले आज़माएं, पूर्ण भरने के बाद, स्मार्ट डेटा की जांच करके देखें कि अभी भी कितने वास्तविककरण किए जा सकते हैं।

यह बहुत महत्वपूर्ण नहीं है कि कितने वास्तविककरण किए गए थे, अधिकांश SSDs कुछ ब्लॉकों के साथ पहले से ही वास्तविक हो चुके manufacter से आए थे, शून्य के साथ एक को 1% से कम पाया है, इसलिए यह महत्वपूर्ण है अनुपात, reallocate बनाम भविष्य कब्जे le reallocations।

सैकड़ों पाँच SSDs के साथ पाँच वर्षों में मृत्यु हो जाने के बाद यह मेरा अनुभव है, कुछ उपयोग के पहले घंटे में, एक सप्ताह में अन्य, एक महीने में अन्य की मृत्यु हो गई; लेकिन सभी ने मुझे ऐसा शून्य पूर्ण फिल किया 2 से 3 साल तक, प्रत्येक दिन एक 13GiB लिखा होने के साथ, 3 * 365 * 13 GiB = 13.9TiB लिखा गया, बहुत कम मैनफ़ोर्स से कम (> 100TiB) कहते हैं।

लेकिन गति मायने रखती है, सबसे अधिक अगर विंडोज पर (लिनक्स पर एक अच्छा 2xHDD LVM2 स्ट्रिपिंग एक ही बूट बार देता है, लेकिन थाय> 25 साल में विफल नहीं होता है), इसलिए एसएसडी का उपयोग 0.21 € प्रति गीगाबाइट (120GHB = 25 €) की कीमत के साथ किया जाता है। इसके लायक (विंडोज के लिए), उनमें से 2 या 3 साल बाद चूहे बदले जा सकते हैं; मुझे आशा है कि प्रौद्योगिकी विश्वसनीयता में सुधार करेगी।

लिनक्स के लिए मैं अब एसएसडी नहीं चाहता हूं जब तक कि थाय अधिक विश्वसनीय नहीं होगा, लेकिन विंडोज (विस्टा, 7 और 10) सिस्टम विभाजन के लिए आवश्यक है (कुछ मामलों में दस गुना कम, विंडोज विस्टा के साथ> 30 मिनट के बजाय बूट करें मेरे पुराने लैपटॉप पर 4min पर जूते)।

हां, जीरो के साथ फुल फिल एक मस्ट है, मेरे अनुभव को देखते हुए।

लेकिन, केवल तभी जब आप SSD को पुनः प्राप्त करते हैं और किसी भी चीज़ के लिए इसका उपयोग करने से पहले।

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

और इसके अलावा, हर बार जब आप इस पर डेटा बदलते हैं, तो एक क्लोन करने की कोशिश करें, एसएसडी लिखकर सूचित करेगा कि ठीक है, बिना पढ़े सेक्टरों पर भी (उन्हें ठीक लिखा जा सकता है लेकिन पढ़ा नहीं गया), कोई भी ऑपरेटिंग सिस्टम ऐसी स्थिति का समर्थन करने के लिए नहीं बनाया गया है , वे सभी सुपरसेट यदि wtite ठीक है डेटा पढ़ा जा सकता है; क्या लिखा गया था अलग डेटा thsn पढ़ने के साथ पठनीय भ्रमित मत करो।

यह एसएसडी और एचडीडी के साथ मेरा अनुभव है। Windows बूट और ऐप्स के लिए मैं SSD का उपयोग करता हूं, लेकिन SSD 3 साल से कम समय में मरने के बाद सामान्य HDD पर किए गए क्लोन के साथ allways, लेकिन gor Linux i का उपयोग 2x या 3x अच्छा 2.5 "HDD ti सामान्य उपयोग पर समान समय मिलता है, जैसा कि SSD देगा। , लेकिन लंबे समय तक चलने (> 25 वर्ष)।

मैं 100GiB के लिए 1000 € का भुगतान नहीं कर रहा हूँ, जो 10 साल के लिए अच्छी तरह से काम करता है, मैं 130GiB हर 2 या 3 साल के लिए 25 € का भुगतान करने के लिए तैयार हूँ। मूल्य मायने रखता है 100 € प्रति वर्ष (उद्यम) बनाम 10 € प्रति वर्ष (यूकोन, सैमसंग, आदि), बस गणित करें।


खराब क्षेत्रों पर लिखने के लिए मजबूर करना वास्तव में उन्हें "ठीक" करने का एक काफी विश्वसनीय तरीका है, जब तक कि आरक्षित क्षेत्र अभी भी उपलब्ध हैं।
कंफ़ेद्दी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.