भ्रष्ट / दुर्गम डिस्क ब्लॉक वाली फाइलों को कैसे पहचाना और ठीक किया जाए

Question

मेरे पास देर से 2011 का मैकबुक प्रो है, जो मावेरिक्स को 10.9.2 पर चला रहा है। इसका एकमात्र HDD एक 750GB ड्राइव है, जिसे Bootcamp के साथ स्वरूपित किया गया है। यह अभी भी बहुत अच्छी तरह से चल रहा है, लेकिन इस पर एक डीफ़्रैग्मेन्ट पास चलाने में, मैंने पहचान लिया है कि फ़ाइलों का एक गुच्छा है जो डीफ़्रैग्मेंटर (iDefrag) द्वारा स्थानांतरित होने से इनकार कर रहे हैं।

iDefrag फ़ाइलों को एक्सेस करते समय 5 के POSIX त्रुटि कोड की रिपोर्ट करता है। यादृच्छिक पर एक को चुनना और शेल में किसी अन्य स्थान पर फ़ाइल को कॉपी करने की कोशिश करना भी एक त्रुटि की रिपोर्ट करता है, जिससे मुझे लगता है कि समस्या वास्तविक है और डिस्क / एफएस के साथ है। Cp का आउटपुट है:

cp: unity_nophysx.nexe: Input/output error

जहाँ तक मुझे जानकारी है, त्रुटि कोड 5 'एक्सेस अस्वीकृत' है, लेकिन डीफ़्रैग प्रक्रिया व्यवस्थापक के रूप में चल रही है और संदिग्ध फ़ाइल पर sudo का उपयोग करके cp चलाने से कोई फर्क नहीं पड़ता है।

डिस्क उपयोगिता, fsck और Apple हार्डवेयर टेस्ट सभी का दावा है कि डिस्क ठीक है। कोई SMART त्रुटियों की रिपोर्ट नहीं की गई, और जब कुछ अनुमतियाँ त्रुटियां थीं, तो वे उन फ़ाइलों के साथ नहीं थे जिनके बारे में iDefrag शिकायत कर रहा है, और डिस्क उपयोगिता ने उन्हें बिना किसी शिकायत के ठीक करने का दावा किया है।

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

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

Comments

मैं आपको सुपरयूज़र पर इस सुंदर विस्तृत चर्चा को पढ़ने की सलाह देता हूं: superuser.com/q/148227 ।

— dan

मैंने परीक्षण किया, दुर्भाग्य से एक स्वस्थ डिस्क पर :), volitans-software.com/smart_utility.php । यह एक बहुत ही सरल और गंभीर उपकरण की तरह दिखता है। आप इसे आज़मा सकते हैं और विशेष रूप से "वास्तविक क्षेत्रों" काउंटर की जांच कर सकते हैं।

— dan

Answer 1

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

1. के साथ अपने डिस्क की एक पूर्ण बैकअप बनाने Time Machineया कार्बन कॉपी cloner

   इस बैकअप की जाँच करें।

2. निम्नलिखित भारी और जोखिम भरा चलाएं (यदि आपके पास आपके फाइलसिस्टम संरचना के बाहर खराब ब्लॉक हैं) कमांड (सुनिश्चित करें कि {} को रिक्त स्थान के काम वाले फाइलनाम उद्धृत किया गया है):

   find / -type f -print -exec dd if="{}" of=/dev/null bs=1m \;
   

यह भारी findकमांड किसी भी सादे फ़ाइल के लिए उसका नाम प्रिंट करेगा (इस प्रकार इसे नहीं पढ़ रहा है, लेकिन सिर्फ इसकी निर्देशिका प्रविष्टि है) और फिर अपने सभी डेटा ब्लॉक का पूर्ण और तेज़ रीडिंग जारी रखें।

खराब ब्लॉकों वाली पहली फ़ाइल को हिट करने पर, यह findकर्नेल को लॉग read errorऑन करने का कारण होगा /var/log/system.log, और यह या तो आपके सिस्टम को पूरी तरह से धीमा कर देगा या ले आएगा। यह ज्यादातर इस सामान्य फिक्स टास्क के लिए समर्पित आंतरिक पूल पर पाए जाने वाले खराब ब्लॉकों को स्थानांतरित करने के लिए हार्ड ड्राइव की क्षमता पर निर्भर करेगा। ख़राब ब्लॉकों वाली यह फ़ाइल अंतिम नाम मुद्रित होगी find।

कागज के एक टुकड़े पर इस फ़ाइल का नाम लिखें! मान लीजिए कि यह फ़ाइल नाम है:

/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9

इस बिंदु पर आपको findहिटिंग ctrl+ द्वारा जल्दी से मारने की संभावना हो सकती है C। यदि इसे अच्छी तरह से मारना विफल हो रहा है, तो बस अपने मैक को क्रैश कर दें।

अपने मैक को रिबूट करने पर, सीधे खराब ब्लॉकों वाली फ़ाइल की जांच करें:

dd if='/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9' of=/dev/null bs=1m

यदि कमांड सही ढंग से समाप्त हो जाती है, तो आपकी डिस्क इस फ़ाइल को पढ़ने और खराब ब्लॉकों को पुनः प्राप्त करने में सक्षम होने के लिए पर्याप्त प्रकाश थी।

• यदि आदेश समाप्त नहीं होता है, तो आप इसे सामान्य रूप से मार नहीं पाएंगे, आपका डेटा पूरी तरह से खो गया है, और आपको अपने मैक को एक बार फिर से क्रैश करना होगा।

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

कर्नेल आपके द्वारा कभी नहीं पढ़े गए ब्लॉक पर रीड एरर को फायर नहीं करेगा।

Comments

अहा, यह बिल्कुल उसी तरह की चाल है जिसकी मैं उम्मीद कर रहा था। पहले पाएं / खोज के साथ dd स्क्रिप्ट डिस्क पर मौजूद सभी फाइलों / ब्लॉक्स को छूती है, और निश्चित रूप से मुझे उन फाइलों का एक गुच्छा मिलता है, जो "इनपुट / आउटपुट एरर" देते हैं, और मैं बस कमांड के लॉग को फाइल में आउटपुट कर सकता हूं और फिर यह पता लगाने के लिए कि कौन सी फाइलें डफ हैं। ऐसा लगता है कि dd कमांड अपने आप में किसी भी प्रकार की स्वचालित फिक्सिंग को ट्रिगर करने के लिए पर्याप्त नहीं है (मुझे यह भी नहीं पता था कि OS X ने ऐसा किया है), लेकिन कम से कम यह मुझे फाइलों की पहचान करने का एक विश्वसनीय तरीका देता है।

— MrCranky

दूसरी तरफ, जब ओएस इन खराब ब्लॉकों के साथ फाइलों से पढ़ने की कोशिश करता है, तो यह दुर्घटनाग्रस्त नहीं होता या बुरी तरह से लटका नहीं होता है। मुझे May 10 20:42:15 ICE kernel[0]: disk0s2: I/O error.लॉग में एक पॉप अप दिखाई देता है, लेकिन कोई सुराग नहीं है कि किस फ़ाइल ने इसे ट्रिगर किया। लेकिन तब कमान काफी खुशी से चलती है।

— MrCranky

आपका कर्नेल BBFH के साथ नहीं लटका है क्योंकि आपकी डिस्क में अभी भी इसके ब्लॉक के भीतर पर्याप्त ब्लॉक उपलब्ध हैं जो खराब ब्लॉक को ठीक कर सकते हैं। ddकुछ भी ठीक नहीं करता है, यह कमांड उद्देश्य डेटा की प्रतिलिपि बनाना और उन्हें जितनी जल्दी हो सके रूपांतरित करना है। डिस्क अभी भी प्रकाश त्रुटियों को ठीक करने में सक्षम है। चौकस रहें, एक डिस्क की कीमत आपके काम के लिए कुछ भी नहीं है।

— दान

हम्म, हाँ, मैंने मान लिया था कि: dd सिर्फ एक फ़ाइल से सभी डेटा को रीम करने के लिए एक डंबल टूल है और इसे कहीं और (हमारे मामले में, पतली हवा में) डालें। वास्तव में क्या मायने रखता है कि फ़ाइल से जुड़े प्रत्येक ब्लॉक को पढ़ा जाता है। मुझे वह नहीं मिल रहा है जो आप उस स्थिति में करने के लिए OS X की अपेक्षा करते हैं। स्पष्ट रूप से कर्नेल इन खराब ब्लॉकों को नहीं पढ़ सकता है, लेकिन क्या आपको लगता है कि डिस्क स्वयं ही उन्हें ठीक कर सकती है और उन्हें ठीक कर सकती है? यदि यह डेटा को मूल ख़राब ब्लॉक से बाहर नहीं निकाल सकता है, तो इसे अन्यत्र कैसे स्थानांतरित करना है?

— MrCranky

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

— दान

Answer 2

बूट के दौरान Command+ धारण करके एकल उपयोगकर्ता मोड में रिबूट S। जब आप एक संकेत देखते हैं (जैसा दिखना चाहिए root #या कुछ इसी तरह का होना चाहिए ), टाइप करें fsck -fऔर दबाएं Return। यह मैक की अंतर्निहित फाइलसिस्टम संगति जांच उपकरण है और आपको स्टार्टअप फाइल सिस्टम के साथ त्रुटियों को खोजने और सुधारने की अनुमति देता है। इस कमांड को तब तक चलाएं जब तक आपको दिखाई न दे **The volume [volume name] was modified.**या टूल लगातार तीन बार विफल न हो।

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

अतिरिक्त जानकारी के लिए आप यहाँ fsck मैनुअल पेज पा सकते हैं ।

Comments

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

— MrCranky

→ म्रान्स्की: सही है! fsckऔर Disk Utilityफ़ाइल-प्रणाली संरचना अखंडता की जाँच कर रहे हैं। वे फाइल-सिस्टम संरचना को आवंटित डिस्क ब्लॉक को पढ़ते हैं। वे डेटा ब्लॉक अखंडता को सत्यापित करने के लिए नहीं बने हैं। इसलिए वे किसी भी पढ़ने की त्रुटि को बढ़ाए बिना विफल ब्लॉक के साथ एक डिस्क पर चल सकते हैं। यदि आप अपनी डिस्क की जांच करना चाहते हैं, यहां तक ​​कि ब्लॉक जो कि दोषपूर्ण हो सकते हैं, लेकिन वास्तव में अप्रयुक्त हैं, तो बस एक बुनियादी उपकरण का उपयोग करें जैसे कि dd if=/dev/disk0 of=/dev/null ibs=1kकिसी अन्य दीवार पर चलाएं tail -f /var/log/system.log। यह मुफ़्त है, चरम है और आपको कोई त्रुटि नहीं छिपाएगा।

— dan

Answer 3

मैं डिस्क कैटलॉग के पुनर्निर्माण के लिए और संभावित रूप से क्षतिग्रस्त फ़ाइलों के लिए स्कैनिंग के लिए अत्यधिक डिस्कवरी की सिफारिश करूंगा ।

कैटलॉग के पुनर्निर्माण के दौरान, यह आपको यह भी बता सकता है कि डिस्क की खराबी के कारण इसमें देरी का अनुभव होता है या नहीं।

Comments

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

— MrCranky

-1 केवल एक उत्तर नहीं है, बल्कि टिप्पणी और उत्तर का मिश्रण है।

— बॉट 47

Answer 4

बुस्कर के जवाब से काम करते हुए, आप स्वचालित रूप से कुछ बहुत भारी कमांड लाइन फू का उपयोग करके ऐसा कर सकते हैं।

sudo find / -type f -print0  | xargs -0 -I{} dd if='{}' of=/dev/null bs=1m 2>&1 | grep 'error' >>badfiles.txt  & 

• sudo: व्यवस्थापक मोड
• find -print0: निरपेक्ष पथ
• xargs -0 -I {}: अगले आदेश में {} स्थानापन्न करें
• dd 2> और 1: stdout में std त्रुटि को पुनर्निर्देशित करें
• स्ट्रिंग त्रुटि की तलाश में grep को पाइप स्टडआउट
• सूची फ़ाइल में परिणाम जोड़ें। ( ध्यान दें : यह बाहरी मीडिया पर होना चाहिए यदि आपको लगता है कि आपकी आंतरिक ड्राइव iffy है)

Answer 5

जैसा कि आप कहते हैं, यह भी स्पष्ट नहीं है कि वे फाइलें क्षतिग्रस्त हैं, कम से कम आपका मैक ऐसा नहीं सोचता है।

प्रत्येक OS अपने कार्यों के लिए अनमोल फ़ाइलें बनाता है (आवश्यक बिंदु, वर्तमान में सक्रिय फ़ाइलें ect ....)। कुछ डिफ्रैग्मेंट उन्हें दिखाएंगे, कुछ नहीं।

तथ्य यह है कि आप उन्हें एक्सेस या स्थानांतरित नहीं कर सकते हैं इसका मतलब यह नहीं है कि वे क्षतिग्रस्त हैं।

आम तौर पर मैक स्वयं की देखभाल करने में बहुत अच्छे होते हैं।

Apple रखरखाव का उपयोग करके किया जाता है: टर्मिनल खोलें और टाइप करें:

sudo periodic daily weekly monthly 

रिटर्न के बाद, अपना व्यवस्थापक पासवर्ड दर्ज करें, और ओएस एक्स आपके लिए चीजों की देखभाल करेगा।

यदि आप रुचि रखते हैं, तो उन पर रिपोर्ट के लिए कंसोल में देखें।

किसी भी I / O त्रुटियों के लिए कंसोल लुक (खोज) में, जो यह दर्शाता है कि आपकी डिस्क में समस्या है, डिस्क उपयोगिता और fsck निष्कर्षों की प्रशंसा करने के लिए शुरू हो रही है।

अवसर पर मैं अतिरिक्त रखरखाव कार्य के लिए ओनेक्स नामक एक निशुल्क उपकरण का उपयोग करता हूं । यह फ्रेंच द्वारा बनाया गया है और जैसा कि वे भोजन करते हैं यह बहुत अच्छा है :)

_{गोमेद, डॉक, क्विक, सफारी, मेल, आईट्यून्स के कुछ छिपे हुए मापदंडों को कॉन्फ़िगर करने के लिए ओनेक्स ओएस एक्स के लिए एक बहुपयोगी उपयोगिता है जो आपको स्टार्टअप डिस्क और इसकी सिस्टम फाइलों की संरचना को सत्यापित करने की अनुमति देता है। लॉगिन विंडो, स्पॉटलाइट, और Apple के कई एप्लिकेशन, कैश को हटाने के लिए, कुछ निश्चित फ़ाइलों और फ़ोल्डरों को हटाने के लिए जो बोझिल हो सकते हैं, और बहुत कुछ।}

इन सबके साथ, मैं डीफ़्रैग्मेन्टेर (iDefrag) का उपयोग करने के आपके निर्णय पर सवाल नहीं उठा रहा हूँ क्योंकि मैं इसे नहीं जानता, बल्कि वैकल्पिक समाधान प्रस्तुत कर रहा हूँ।

Comments

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

— MrCranky

गोमेद पर - यह फिर से डिस्क उपयोगिता की तुलना में थोड़ा अधिक कर रहा है - डिस्क की स्मार्ट स्थिति की जाँच करना और फिर fsck स्टाइल डायग्नोस्टिक चलाना (जैसा कि हमने सोचा है कि वहाँ कुछ भी गलत नहीं है)

— MrCranky

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

— MrCranky

Answer 6

जैसा कि अनुचित लगता है, कुछ भी करने से पहले आपको अपने सभी डेटा को एक ज्ञात अच्छे ड्राइव पर डुप्लिकेट करना चाहिए। यदि इंस्टॉलर से बूट करना और डेटा की प्रतिलिपि बनाना विफल हो जाता है, तो 'dd' नामक एक कमांड लाइन उपयोगिता है जो निम्न-स्तरीय डुप्लिकेटिंग और कहीं अधिक असम्बद्ध तरीके से कर सकती है।

 man dd

उपयोग और उचित सिंटैक्स सहित dd के बारे में अधिक जानकारी के लिए।

---

मैट के पोस्ट के लिए एक और वोट, बूट सिंगल-यूज़र मोड, और रन

 fsck -fy 

जब तक fsck त्रुटियों की रिपोर्ट करना बंद नहीं करता, तब तक वह और अधिक।

---

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

---

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

Comments

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

— MrCranky

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

— चिलिन

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

— MrCranky

Answer 7

डिस्क रीड एरर के कारण अपनी संपूर्णता में पढ़ी जा सकने वाली एकल फ़ाइल के लिए, आप ddफ़ाइल को बाहरी वॉल्यूम में डुप्लिकेट करने के लिए उपयोगिता का उपयोग कर सकते हैं , उन ब्लॉक के लिए एनयूएल बाइट्स को प्रतिस्थापित नहीं किया जा सकता है जिन्हें पढ़ा नहीं जा सकता है। यह एक अलग मात्रा (उदाहरण के लिए नीचे उदाहरण में "USB डिस्क" की नकल करने के लिए अत्यधिक अनुशंसित है)।

उदाहरण:

dd if=/path/to/damaged/file of=/Volumes/USB\ Disk/file bs=512 conv=noerror,sync

512-बाइट ब्लॉक का उपयोग करके, अधिकतम पठनीय ब्लॉक पुनर्प्राप्त किए जाएंगे।

पुनर्प्राप्ति में एक लंबा समय लग सकता है, क्योंकि कर्नेल प्रत्येक असफल पढ़ने पर कुछ समय के लिए अवरुद्ध हो जाएगा।