क्या एक HDD तेजी से शून्य के साथ ओवरराइट किया गया है?


52

मेरे पास एक पीसी था जिसमें दो ओएस स्थापित थे, जो कि हार्ड ड्राइव मैंने UbuntuUSB से डिस्क का उपयोग करके मिटा दिया था। मैंने जल्दी मिटा दिया। जैसा कि मैं समझता हूं, उसने विभाजन तालिका को हटा दिया, लेकिन सभी फाइलें और जीरो अभी भी एचडीडी पर हैं। मैंने तब नई विभाजन तालिका बनाई, और Win10 स्थापित किया।

प्रश्न: अगर मैं इसे जीरो से ओवरराइड करता तो क्या अब एचडीडी का काम (पढ़ना / लिखना) तेजी से होता?
या: "गंदे" HDD की तुलना में तेजी से शून्य-अधिलेखित एचडीडी पर जानकारी लिख रहा है?


1
संभवतः इस संबंध में एटीए सिक्योर इरेज़र का उल्लेख करने योग्य है । यह ओपी के प्रत्यक्ष उपयोग का नहीं हो सकता है, लेकिन दूसरों के लिए उपयोगी हो सकता है।
स्टीफन

क्या आप (चुंबकीय) HDD, SSD, या दोनों के बारे में पूछ रहे हैं? उत्तर निर्भर करता है।
smci

यह ध्यान देने योग्य है कि भौतिक रूप से संबोधित फ्लैश मेमोरी, जैसा कि एक माइक्रोकंट्रोलर पैकेज में पाया जा सकता है, पहले से डिफ़ॉल्ट होने पर साफ हो जाएगा, क्योंकि आप इस कदम को सामने के रास्ते से बाहर निकालते हैं।
मूसबॉयस

जवाबों:


92

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

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

ठोस राज्य ड्राइव एक समान प्रक्रिया से गुजरते हैं; डेटा के एक नए ब्लॉक को लिखने से पहले वे स्वचालित रूप से एक ब्लॉक की पिछली सामग्री को मिटा देते हैं, इसलिए एसएसडी पर सभी शून्य लिखने से डिवाइस पर अनावश्यक पहनने का कारण होगा, क्योंकि फ्लैश तकनीक केवल एक चर को मिटा सकती है, लेकिन विफलता से पहले कई बार परिमित होती है। । पेश किया गया वस्त्र केवल कुल शुल्क चक्रों का 0.01% जैसा कुछ होगा, लेकिन यह कुछ ऐसा है जिसे आप नियमित रूप से करने से बचना चाहेंगे।


9
can only be erased a certain number of times- दरअसल, संख्या इतनी निश्चित नहीं है। भिन्नता काफी बड़ी है
रुस्लान

19
@Ruslan गरीब शब्द पसंद है, मुझे लगता है। यह निश्चित नहीं है (केवल मृत्यु और कर निश्चित लगते हैं), लेकिन यह निश्चित रूप से परिमित है, और निर्माता केवल "कर्तव्य चक्र" की संख्या तक के प्रदर्शन की गारंटी देते हैं।
फेयरफॉक्स

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

5
आपके उत्तर के साथ दो मुद्दे; 1) Solid state drives go through a similar process। यह सही नहीं है। SSDs करने के तरीके में हार्ड ड्राइव एक रीड / इरेज / राइट साइकिल के माध्यम से नहीं जाते हैं। वे पहले मिटाए बिना सेक्टरों को ओवर-द-फ्लाई को ओवरराइट कर सकते हैं। 2) A long run of 0s or 1s could actually cause sync issues when trying to read the dataइसके अलावा सही नहीं है। हार्ड ड्राइव क्षेत्रों में उन क्षेत्रों के बीच एक अंतर होता है जहां वे सेक्टर संख्या, सिंक बिट्स और ईसीसी डेटा रिकॉर्ड करते हैं। पता और सिंक डेटा सिर को पलस्तर पर "खो" होने से बचाता है। एक 4k सेक्टर वास्तव में 4211 बाइट्स हैं क्योंकि इसकी वजह से यह लंबा है।
वेस सईद

2
@WesSayeed "इसी तरह की प्रक्रिया" का अर्थ है कि एसएसडी एक बार में पूरे सेक्टर भी लिखता है। सच है, सामान्य एचडीडी पहले नहीं मिटाता है, लेकिन यह अभी भी एक समान प्रक्रिया है; दोनों एक साथ पूरे सेक्टर लिखते हैं। और हाँ, मैं अंतर-सेक्टर के अंतर से अवगत हूँ, जिसमें ECC और whatnot शामिल हैं, लेकिन वे अभी भी MMFM / GCR जैसी किसी चीज़ का उपयोग यह सुनिश्चित करने के लिए करते हैं कि घड़ी सेक्टर के भीतर वंशानुक्रम में न आए, जिसका अर्थ है कि उनके पास नहीं हो सकता है एक पंक्ति में बहुत सारे शून्य बिट्स।
phyrfox

53

नहीं, यह तेज नहीं होगा। डेटा ओवरराइट किए जाने के बावजूद लेखन में उतना ही समय लगता है।


12
यह एक चुंबकीय HD के लिए सच है, लेकिन यह प्रशंसनीय है कि आंतरिक संपीड़न का उपयोग करते हुए एक एसएसडी और TRIMज़ीरो के साथ ओवरराइट किए जाने पर समर्थन तेज नहीं हो सकता है। वे फ्लैश स्टोरेज पर कम वास्तविक स्थान लेते हैं, जिससे फ्लैश रीमैपिंग लेयर के साथ काम करने के लिए अधिक जगह बचती है। तो यह TRIM / त्याग जैसा होगा।
पीटर कॉर्डेस

2
@PeterCordes - सच है, आज वास्तव में इस्तेमाल होने वाले SSDs का अनुपात TRIM का समर्थन नहीं करता है? मुझे पता है कि मैंने कई उत्पाद पीढ़ियों से और कई प्रकार के निर्माताओं (उच्च अंत से सभी तरह से अनब्रांडेड / स्टोर ब्रांडेड तक) का उपयोग किया है, उनमें से सभी जो मैंने किया है।
जूल्स

1
@PeterCordes सवाल यह है कि ज़ीरो को अधिलेखित करने के बजाए अधिलेखित किया जा रहा हैऐसा लगता है कि आंतरिक संपीड़न बंद नहीं हुआ है क्योंकि यह केवल एक सेक्टर ग्रैन्युलैरिटी पर किया जा सकता है और इससे थ्रूपुट को बनाए रखने में परेशानी हो सकती है। अगर एसएसडी में प्रोविजनिंग स्पेस नहीं होता और जीरो से फिजिकल मैप में निर्माता जीरो मैप करते, तो जीरो पर राइटिंग तेज हो सकती थी, ताकि जीरो से भरी डिस्क वास्तव में "खाली" फ्लैश पेज से बने।
मार्गरेट ब्लूम

@ जूल्स: कुछ पुराने एसएसडी ने टीआरआईएम का समर्थन नहीं किया, क्योंकि पहले एसएसडी के अस्तित्व में आने के बाद टीआरआईएम को केवल एटीए मानक में जोड़ा गया था, और फिर नियंत्रकों को इसका समर्थन शुरू करने में समय लगा। मेरे पास एक पुराने लैपटॉप में है। (मुझे लगता है कि इसके लिए एक फर्मवेयर अद्यतन उपलब्ध है जो TRIM समर्थन जोड़ता है)। मुझे यकीन नहीं है कि अगर TRIM के बिना उन पुराने SSDs में से किसी ने आंतरिक संपीड़न का उपयोग किया। मुझे कहना चाहिए कि इन दिनों ऐसे SSD दुर्लभ हैं, लेकिन इस उत्तर की तरह कंबल वाले बयान मुझे हमेशा काउंटरटेम्पल या विशेष मामलों की तलाश करने के लिए प्रेरित करते हैं जहां वे पकड़ नहीं रखते हैं।
पीटर कॉर्डेस

3
@ जूल्स SSDs का एक बड़ा हिस्सा TRIM का समर्थन नहीं करता है, ज्यादातर यूएसबी स्टिक या एसडी कार्ड या एमएमसी की तरह सरल होता है। बहुत ज्यादा कुछ भी जो एटीए नहीं है।
वन

10

यह इस पर निर्भर करता है:

  • चाहे वह मैकेनिकल एचडीडी हो या एसएसडी।

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

  • चाहे ड्राइव पर अपठनीय क्षेत्र हों।

कई ड्राइव "खराब स्पॉट" की एक छोटी संख्या विकसित करेंगे यदि कई वर्षों तक कठोर उपयोग किया जाता है। जो पहले से ही सामना किया गया है वह स्मार्ट डेटा में "लंबित अनिश्चित" के रूप में दिखाई देगा।

यदि कोई अपठनीय क्षेत्र नहीं हैं, तो एक यांत्रिक एचडीडी को अधिलेखित होने से लाभ नहीं होता है, हालांकि यह बहुत अधिक समय तक अप-फ्रंट का उपभोग करने से अलग कोई नुकसान नहीं करता है।

वहाँ तो कर रहे हैं कुछ अपठनीय क्षेत्रों, पढ़ने के लिए उन्हें एक लंबा समय लगेगा प्रयास करता है, और ड्राइव खाली क्षणों, जो प्रदर्शन को प्रभावित करेगा में डेटा को ठीक करने की कोशिश कर रखना होगा। उन्हें अधिलेखित करने से HDD को मौजूदा डेटा को छोड़ने के लिए संकेत मिलेगा, परीक्षण करें कि क्या भौतिक स्थान अभी भी भंडारण के लिए उपयोग किया जा सकता है, और अन्यथा खाली स्थान आवंटित करें। यह "लंबित अपरिवर्तनीय" काउंटर को भी रीसेट करेगा।

टीएल; डीआर - आम तौर पर, यह मत करो।


1
यह भी ध्यान देने योग्य है कि शून्य के साथ ओवरराइटिंग संभवत: फ्लैश करने के लिए संभवतः सबसे खराब चीज है: फ्लैश मेमोरी के एक ब्लॉक को लिखने की प्रक्रिया इसे मिटाना है (जो बिट्स को 1 पर सेट करता है) और फिर बिट्स में लिखने के लिए आवश्यक है Be 0. मैं निश्चित नहीं हूं, लेकिन मुझे लगता है कि अगर किसी सेक्टर में सभी शून्य लिखे गए हैं, तो यह एक यादृच्छिक पैटर्न लिखने की तुलना में डिवाइस की लंबी उम्र के लिए अधिक नुकसान करेगा, जो सभी 1s लिखने की तुलना में अधिक नुकसान करेगा, क्योंकि बाद के ऑपरेशन को कम शक्ति की आवश्यकता होगी यदि कम 0s ((इस बारे में निश्चित नहीं हैं) और इसलिए कम नुकसान (??) करते हैं।
जूल्स

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

यह एक फ्लैश ड्राइव को अधिलेखित करने के लिए भी बेकार है जो कि ओवरप्रॉवनिंग स्थान के कारण होता है।
वन

किसी को SSD का उपयोग करने के बारे में बहुत अधिक चिंता करने की आवश्यकता नहीं है। जर्मन लिंक: heise.de/-3755009
user3549596

5

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


2

जब आप "धीमी प्रारूप" कर रहे होते हैं, तो आमतौर पर ड्राइव पर खराब ब्लॉकों के लिए सतह परीक्षण भी किया जाता है, इसलिए यह पुराने एचडीडी के लिए उचित हो सकता है, लेकिन आपको किसी भी आर / डब्ल्यू के प्रदर्शन अंतर पर ध्यान नहीं देना चाहिए।


0

HDDs या SDDs के लिए भी कोई अंतर नहीं है।

एचडीडी के मामले में, ड्राइव पर तारीख चुंबकीय रूप से प्रत्येक क्षेत्र पर बदल जाती है जिसे आप लिखते हैं इसलिए यह अप्रासंगिक है कि आप वहां क्या लिखते हैं।

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

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


0

नहीं, कोई गति अंतर नहीं होगा, लेकिन आपके पास अनावश्यक पहनने और असफलता का एक अनावश्यक मौका है।

पारंपरिक हार्डडिस्क एक सरल छद्म आयामी जनरेटर के साथ डेटा को एन्कोड करते हैं, अधिक आधुनिक वाले और (वस्तुतः) सभी SSDs एईएस के साथ डेटा को हमेशा एनकोड करते हैं। इसका कारण यह है कि रैंडम डेटा (या रैंडम-लुकिंग डेटा) को स्टोरेज-लेवलिंग के लिए अधिक अनुकूल है, चुंबकीय और ठोस दोनों अवस्थाओं में, लेकिन विशेष रूप से उत्तरार्द्ध के मामले में (इस प्रकार एईएस पहले और सबसे पहले इस्तेमाल किया जाता है) बिट्स हाथापाई करने के लिए, लेकिन एक मुफ्त बोनस के रूप में, आप बिना किसी अतिरिक्त लागत के सुरक्षा कर सकते हैं)।

इस प्रकार, बहुत सारे शून्य लिखना प्रभावी रूप से "थोड़े यादृच्छिक बिट्स" का एक बहुत कुछ लिखता है।

यह है, और यह किसी भी तरह से (या ओवरराइट) एक या दूसरे को पढ़ने के लिए तेजी से नहीं है।

दूसरी ओर, संपूर्ण ड्राइव को अधिलेखित करने का अर्थ है कुछ अरब क्षेत्रों को लिखना। जबकि हार्डड्राइव में (विशुद्ध रूप से काल्पनिक) असफलता की दर इतनी कम होती है कि वे ऐसे लगते हैं जैसे "कभी नहीं होता", आधुनिक डिस्क के विशाल आकार को देखते हुए "कभी नहीं होता" बहुत अधिक है "जैसा कि होने की संभावना है"। यह इस कारण से है कि उदाहरण के लिए RAID-5 की अब अनुशंसा नहीं की जाती है क्योंकि असफल डिस्क के बाद पुनः सिंक करने की कोशिश करते समय एक अपरिवर्तनीय विफलता का सामना करने की संभावना इतनी अधिक है कि यह एक व्यावहारिक चिंता बन सकती है।

इसका क्या मतलब है? खैर, इसका मतलब सामान्य तौर पर कुछ भी नहीं है, लेकिन आवश्यकता के बिना पूरी डिस्क को ओवरराइट करना शायद एक अच्छा विचार नहीं है। यहां तक ​​कि सुरक्षित मिटाए जाने के लिए, यदि इसका इरादा है, तो आजकल बहुत बेहतर (तेज और अधिक विश्वसनीय) तरीके मौजूद हैं।

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