SMART डेटा में सिंगल करेंट_पेंडिंग_सेक्टर को हटाने / डायग्नोस करने की कोशिश की जा रही है


18

मैं एक ताजा लिनक्स स्थापित करने की प्रक्रिया में हूँ और इससे पहले कि मैं यह करने के लिए जाऊं कि मुझे लगा कि एचडीडी स्वास्थ्य को सत्यापित करने का यह एक अच्छा समय है क्योंकि जरूरत पड़ने पर मैं एचडीडी पर किसी भी डेटा को सुरक्षित रूप से अधिलेखित कर सकता हूं।

पहले मैंने स्मार्टमोनोलस के साथ जाँच करने की कोशिश की ... माई सीगेट एचडीडी एक वर्तमान लंबित क्षेत्र और एक ऑफ़लाइन अप्राप्य (संभवतः एक ही एक) की रिपोर्ट करता है। Reallocated क्षेत्र की गणना शून्य है।

5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
...
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1

हालाँकि SMART सेल्फ टेस्ट (छोटी, लंबी, ऑफलाइन, कनवेंस) में कोई त्रुटि नहीं है।

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      6631         -
# 2  Conveyance offline  Completed without error       00%      6630         -
# 3  Extended offline    Completed without error       00%      6622         -
# 4  Short offline       Completed without error       00%      6600         -
# 5  Extended offline    Completed without error       00%      6632         -

मैंने ड्राइव पर बैडब्लॉक -एसवीवी (फुल रीड-राइट 4 पैटर्न पास टेस्ट) चलाने की भी कोशिश की है और कोई बुरा ब्लॉक नहीं मिला। मैंने तब गाइड का अनुसरण किया (संभव हद तक, क्योंकि मैंने बैडब्लॉक चलाने के बाद अपनी फाइलसिस्टम को डिलीट कर दिया था) यहाँ पाया गया: http://smartmontools.sourceforge.net/badblockhowto.html

वहाँ यह कहता है कि यदि मैं सभी शून्य के साथ क्षेत्र को अधिलेखित करता हूं तो डिस्क को लंबित क्षेत्र को स्थानांतरित करना (पुनः प्राप्त करना) चाहिए। बैडब्लॉक अंतिम लेखन पैटर्न सभी शून्य है ताकि इसे करना चाहिए था। हालाँकि कुछ भी नहीं बदला है, मेरे पास अभी भी उस लंबित सेक्टर की संख्या 1 है।
मैंने तब यह पता लगाने की कोशिश की कि कौन सा सेक्टर समस्याग्रस्त है और स्मार्ट आउटपुट में एक त्रुटि लॉग है:

Error 2 occurred at disk power-on lifetime: 5344 hours (222 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 7c 1b 1a 02 ae  Error: ABRT at LBA = 0x0e021a1b = 235018779

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  20 20 7f 18 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 17 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 01 00 00 a0 00      00:08:59.830  READ SECTOR(S)
  91 20 3f 01 00 00 af 00      00:08:59.826  INITIALIZE DEVICE PARAMETERS [OBS-6]
  10 20 01 01 00 00 a8 00      00:08:59.678  RECALIBRATE [OBS-4]

Error 1 occurred at disk power-on lifetime: 5009 hours (208 days + 17 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 b7 8c 02 e0  Error: UNC at LBA = 0x00028cb7 = 167095

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 20 1e 9e 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 80 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 62 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 44 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 26 8c 02 e0 00      00:02:20.690  READ DMA EXT

तो जाहिर है ड्राइव में दो त्रुटियां थीं।

84 51 7c 1b 1a 02 ae  Error: ABRT at LBA = 0x0e021a1b = 235018779

तथा

40 51 00 b7 8c 02 e0  Error: UNC at LBA = 0x00028cb7 = 167095

इसलिए मैंने मान लिया कि ये सेक्टर नंबर हैं: 167095 और 235018779। और मैंने dd के साथ शून्य लिखने की कोशिश की:

dd if=/dev/zero of=/dev/sda bs=512 count=1 seek=167095

अब उस एक ने ठीक किया। हालाँकि जब मैंने दूसरे सेक्टर के साथ कोशिश की:

dd if=/dev/zero of=/dev/sda bs=512 count=1 seek=235018779

मुझे dd मिलता है : '/ dev / sda': तलाश नहीं कर सकता: अमान्य तर्क । मैंने तब देखा कि मेरे HDD में केवल 234441658 सेक्टर हैं। तो यह सीमा से बाहर है। लेकिन फिर SMART ने उस पते पर त्रुटि की रिपोर्ट क्यों की ?!

क्या कोई मुझे यह पता लगाने में मदद कर सकता है और मुझे यह सलाह भी दे सकता है कि अगर मैं इसे गलत कर रहा हूं तो इसे सही तरीके से कैसे करें? मुझे संदेह है कि शायद मैं dd के साथ ब्लॉक आकार 512 का उपयोग करने में गलत हूं। यह स्मार्ट द्वारा रिपोर्ट किए गए सेक्टर आकार है। शायद उन एलबीए पतों को बाइट्स नहीं हैं जिन्हें मैंने bs = 1 सेट करने की कोशिश की थी और एचडीडी के उन पतों पर केवल एक बाइट लिख रहा था। यह काम किया (dd लिखने की प्रक्रिया) ... हालांकि लंबित क्षेत्र की गिनती उसके बाद भी नहीं बदली। मैंने इस क्षेत्र को पुनः प्राप्त करने के लिए ड्राइव को 'मजबूर' करने की कोशिश के लिए सिंक और स्मार्टक्ट्ल-टी ऑफ़लाइन / देव / एसडीए भी कहा । कुछ भी तो नहीं...

यहाँ मेरा पूरा स्मार्टक्ट्ल --all / dev / sda आउटपुट है:

smartctl 5.43 2012-06-30 r3573 [i686-linux-2.6.32-358.el6.i686] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.9
Device Model:     ST3120811AS
Serial Number:    6PT1N4VZ
Firmware Version: 3.AAE
User Capacity:    120,034,123,776 bytes [120 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Mon Nov 18 12:03:00 2013 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                    was completed without error.
                    Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                    without error or no self-test has ever 
                    been run.
Total time to complete Offline 
data collection:        (  430) seconds.
Offline data collection
capabilities:            (0x5b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    Offline surface scan supported.
                    Self-test supported.
                    No Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                    General Purpose Logging supported.
Short self-test routine 
recommended polling time:    (   1) minutes.
Extended self-test routine
recommended polling time:    (  51) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   084   077   006    Pre-fail  Always       -       185600113
  3 Spin_Up_Time            0x0003   095   095   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   098   098   020    Old_age   Always       -       2185
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   073   055   030    Pre-fail  Always       -       25890559714
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       6632
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   098   098   020    Old_age   Always       -       2229
187 Reported_Uncorrect      0x0032   099   099   000    Old_age   Always       -       1
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   071   056   045    Old_age   Always       -       29 (Min/Max 25/29)
194 Temperature_Celsius     0x0022   029   044   000    Old_age   Always       -       29 (0 13 0 0 0)
195 Hardware_ECC_Recovered  0x001a   052   046   000    Old_age   Always       -       194244099
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
202 Data_Address_Mark_Errs  0x0032   066   219   000    Old_age   Always       -       34

SMART Error Log Version: 1
ATA Error Count: 2
    CR = Command Register [HEX]
    FR = Features Register [HEX]
    SC = Sector Count Register [HEX]
    SN = Sector Number Register [HEX]
    CL = Cylinder Low Register [HEX]
    CH = Cylinder High Register [HEX]
    DH = Device/Head Register [HEX]
    DC = Device Command Register [HEX]
    ER = Error register [HEX]
    ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 2 occurred at disk power-on lifetime: 5344 hours (222 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 7c 1b 1a 02 ae  Error: ABRT at LBA = 0x0e021a1b = 235018779

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  20 20 7f 18 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 17 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 01 00 00 a0 00      00:08:59.830  READ SECTOR(S)
  91 20 3f 01 00 00 af 00      00:08:59.826  INITIALIZE DEVICE PARAMETERS [OBS-6]
  10 20 01 01 00 00 a8 00      00:08:59.678  RECALIBRATE [OBS-4]

Error 1 occurred at disk power-on lifetime: 5009 hours (208 days + 17 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 b7 8c 02 e0  Error: UNC at LBA = 0x00028cb7 = 167095

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 20 1e 9e 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 80 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 62 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 44 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 26 8c 02 e0 00      00:02:20.690  READ DMA EXT

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      6631         -
# 2  Conveyance offline  Completed without error       00%      6630         -
# 3  Extended offline    Completed without error       00%      6622         -
# 4  Short offline       Completed without error       00%      6600         -
# 5  Extended offline    Completed without error       00%      6632         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

अपडेट करें:

जैसा कि मैंने लूट के उत्तर में सुझाव दिया था कि मैंने पूरे HDD को शून्य से अधिलेखित करने की कोशिश की थी। SMART मान की जाँच की और फिर पूरे HDD को पढ़ना शुरू किया। फिर से स्मार्ट मूल्यों की जाँच की। परिणाम यह है: लंबित / वास्तविक क्षेत्र गणना के संबंध में SMART मान दोनों मामलों में, लिखने के तुरंत बाद और फिर पढ़ने के बाद नहीं बदलते हैं। पुनः उत्पन्न 0. लंबित 1।


1
मुझे लगता है कि आपके ड्राइव में 234441658 सेक्टर हैं, लेकिन खराब क्षेत्रों के स्थान पर बैकअप किए गए सेक्टरों की संख्या इस संख्या में नहीं है।
ग्रोनोस्तज

हम्म, ताकि सेक्टर 235018779 पर त्रुटि का मतलब बैकअप सेक्टरों में त्रुटि होगी ... क्या यह संभव है?
इवान कोवासेविच

1
ठीक है, बैकअप सेक्टर भी भ्रष्ट हो सकते हैं। अन्यथा हम केवल बैकअप क्षेत्रों से हार्ड ड्राइव को "अमर" बना देंगे।
gronostaj

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

1
यह मानते हुए कि 235018779 सेक्टर एक बैकअप सेक्टर है। इसका मतलब है कि मेरे पास कम से कम 235018779 - 234441658 = 577121 बैकअप सेक्टर होने चाहिए। बैकअप सेक्टर में यह लगभग 282 एमबी है। मुझे बहुत कुछ (बहुत अधिक) लगता है। या यह है? बस जोर से सोच, शायद यह एक बैकअप सेक्टर नहीं है लेकिन स्मार्ट डायग्नोस्टिक्स में गड़बड़ है?
इवान कोवासेविक

जवाबों:


15

जब कोई रीड विफल होता है, तो एक सेक्टर लंबित होता है। यदि बाद में लिखने में विफल रहता है तो लंबित क्षेत्र को फिर से चिह्नित किया जाएगा। यदि लेखन सफल होता है, तो इसे वर्तमान लंबित क्षेत्रों से हटा दिया जाता है और इसे ठीक मान लिया जाता है। (सटीक व्यवहार थोड़ा अलग हो सकता है और मैं बाद में जाऊंगा, लेकिन यह अब के लिए एक पर्याप्त निकट सन्निकटन है।)

जब आप दौड़ते हैं badblocks -w, तो प्रत्येक पैटर्न पहले लिखा जाता है, फिर पढ़ें। यह संभव है कि परतदार क्षेत्र के लिए लेखन सफल हो लेकिन बाद में पढ़ी गई विफलता विफल हो जाती है, जो इसे फिर से लंबित क्षेत्र सूची में जोड़ देती है। मैं पूरी डिस्क के साथ शून्य लिखने की कोशिश करूँगा dd if=/dev/zero of=/dev/sda, SMART स्थिति की जाँच कर, फिर पूरे डिस्क को पढ़ने dd if=/dev/sda of=/dev/nullऔर SMART स्थिति को फिर से जाँचने के साथ ।

अपडेट करें:

आपके पहले के परिणामों के आधार पर badblocks -w, मुझे उम्मीद है कि पूरी डिस्क लिखने के बाद लंबित क्षेत्र को साफ कर दिया जाएगा। लेकिन जब से ऐसा नहीं हुआ, यह कहना सुरक्षित है कि यह डिस्क अपेक्षा के अनुरूप व्यवहार नहीं कर रही है।

चलो वर्तमान लंबित क्षेत्र गणना के विवरण की समीक्षा करें :

"अस्थिर" क्षेत्रों की गणना (अप्राप्य पढ़ने की त्रुटियों के कारण, रीमेक होने की प्रतीक्षा)। यदि किसी अस्थिर क्षेत्र को बाद में सफलतापूर्वक पढ़ा जाता है, तो इस क्षेत्र का पुन: उपयोग किया जाता है और यह मान घट जाता है। एक सेक्टर पर त्रुटियों को पढ़ें क्षेत्र को तुरंत रीमैप नहीं किया जाएगा (क्योंकि सही मूल्य नहीं पढ़ा जा सकता है और इसलिए रीमैप का मूल्य ज्ञात नहीं है, और बाद में यह पठनीय भी हो सकता है); इसके बजाय, ड्राइव फ़र्मवेयर याद रखता है कि सेक्टर को रीमैप करने की आवश्यकता है, और अगली बार इसे लिखे जाने पर इसे रीमैप कर देगा। [२ ९] हालाँकि कुछ ड्राइव लिखे जाने पर ऐसे सेक्टर को तुरंत रीमैप नहीं करेंगे; इसके बजाय ड्राइव पहले समस्या क्षेत्र में लिखने का प्रयास करेगा और यदि लेखन कार्य सफल होता है, तो क्षेत्र को अच्छा चिह्नित किया जाएगा (इस मामले में, "रियलक्लास इवेंट काउंट" (0xC4) नहीं बढ़ाया जाएगा)।

अब महत्वपूर्ण बिंदुओं की समीक्षा करते हैं:

... ड्राइव फ़र्मवेयर याद रखता है कि सेक्टर को रीमेक करने की आवश्यकता है, और अगली बार इसे लिखे जाने पर इसे रीमैप कर देगा। [२ ९] हालाँकि कुछ ड्राइव लिखे जाने पर ऐसे सेक्टर को तुरंत रीमैप नहीं करेंगे; इसके बजाय ड्राइव पहले समस्या क्षेत्र में लिखने का प्रयास करेगा और यदि लेखन कार्य सफल होता है तो क्षेत्र को अच्छा चिह्नित किया जाएगा।

दूसरे शब्दों में, लंबित क्षेत्र को या तो तुरंत हटा दिया जाना चाहिए, या ड्राइव को सेक्टर को लिखने का प्रयास करना चाहिए और दो चीजों में से एक होना चाहिए:

  1. लेखन विफल रहा, जिस स्थिति में लंबित क्षेत्र को फिर से तैयार किया जाना चाहिए था।
  2. लेखन सफल रहा, जिस स्थिति में लंबित क्षेत्र को साफ कर दिया जाना चाहिए था ("चिह्नित अच्छा")।

मैंने पहले इस पर संकेत दिया था, लेकिन विकिपीडिया के करेंट पेंडिंग सेक्टर के विवरण से पता चलता है कि वर्तमान में लंबित क्षेत्र की गिनती पूर्ण डिस्क लिखने के बाद हमेशा शून्य होनी चाहिए । चूँकि यहाँ ऐसा नहीं है, हम यह निष्कर्ष निकाल सकते हैं कि या तो (a) विकिपीडिया गलत है (या आपकी ड्राइव के लिए कम से कम गलत है), या (b) ड्राइव का फर्मवेयर इस त्रुटि स्थिति को ठीक से नहीं संभाल सकता है (जिसे मैं फर्मवेयर बग मानूंगा )।

यदि किसी अस्थिर क्षेत्र को बाद में सफलतापूर्वक पढ़ा जाता है, तो इस क्षेत्र का पुन: उपयोग किया जाता है और यह मान घट जाता है।

चूंकि वर्तमान लंबित क्षेत्र की गिनती पूरी ड्राइव को पढ़ने के बाद भी अपरिवर्तित है, इसलिए हम यह दावा कर सकते हैं कि या तो (ए) सेक्टर को सफलतापूर्वक नहीं पढ़ा जा सकता है या (b) सेक्टर को सफलतापूर्वक पढ़ा और चिह्नित किया गया था, लेकिन एक पढ़ने में त्रुटि हुई थी विभिन्न क्षेत्र। लेकिन चूँकि वास्तविक क्षेत्र की गणना पढ़ने के बाद अभी भी 0 है, हम एक संभावना के रूप में (बी) को बाहर कर सकते हैं और यह निष्कर्ष निकाल सकते हैं कि लंबित क्षेत्र अभी भी अपठनीय था।

इस बिंदु पर, यह जानना उपयोगी होगा कि क्या ड्राइव ने कोई नई स्मार्ट त्रुटियों को लॉग किया है। मेरा अगला सुझाव यह जांचने वाला था कि क्या सीगेट में आपके ड्राइव के लिए फर्मवेयर अपडेट है , लेकिन ऐसा लगता है कि वे नहीं हैं।

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

e2fsck -l फ़ाइल नाम

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

(ध्यान दें कि e2fsck -cइसे पसंद किया जाता है e2fsck -l filename, और आप इसे आज़माना भी चाह सकते हैं, लेकिन आपके परिणामों के आधार पर इस प्रकार, मुझे अत्यधिक संदेह है कि e2fsck -c को कोई भी ख़राब ब्लॉक मिलेगा।)

बेशक, आपको फ़ाइल सिस्टम ब्लॉक नंबर में दोषपूर्ण क्षेत्र के LBA (SMART द्वारा प्रदान) को परिवर्तित करने के लिए कुछ अंकगणित करना होगा। बुरा ब्लाकों HowTo एक आसान सूत्र प्रदान करता है:

  b = (int)((L-S)*512/B)
where:
b = File System block number
B = File system block size in bytes
L = LBA of bad sector
S = Starting sector of partition as shown by fdisk -lu
and (int) denotes the integer part.

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

एक अन्य विकल्प: संदिग्ध खराब ब्लॉक के आसपास विभाजन जब आप अपना ओएस स्थापित करते हैं, तो आप त्रुटि के आसपास विभाजन करने का भी प्रयास कर सकते हैं। अगर मैंने अपना अंकगणित ठीक किया, तो त्रुटि लगभग 81.589 एमबी की है, इसलिए या तो छोटा बना सकते हैं और सेक्टर 167095 के बाद अपना अगला विभाजन शुरू कर सकते हैं, या पहले 82 एमबी या पूरी तरह से छोड़ सकते हैं।

ABRT 235018779 दुर्भाग्य से, सेक्टर 235018779 में ABRT त्रुटि के लिए, हम केवल अनुमान लगा सकते हैं, लेकिन ATA8-ACS कल्पना हमें कुछ सुराग देती है।

अटैचमेंट 8 पर काम करने वाले ड्राफ्ट से - एटीए / एटीएपीआई कमांड सेट (एटीए 8-एसीएस) :

6.2.1 एबॉर्ट (ABRT) त्रुटि बिट 2. यदि कमांड समर्थित नहीं है तो एबॉर्ट को एक पर सेट किया जाएगा। यदि डिवाइस कमांड द्वारा अनुरोध की गई कार्रवाई को पूरा करने में सक्षम नहीं है, तो गर्भपात एक पर सेट किया जा सकता है। यदि IDNF एक पर सेट नहीं है, तो उपयोगकर्ता-सुलभ पते की सीमा के बाहर एक पते का अनुरोध करने पर गर्भपात भी एक पर सेट किया जाएगा।

ABRT (कई READ SECTOR (S) की अगुवाई करने वाले कमांड्स की देखरेख के बाद रिकैलिब्रेशन और रीइंबर्समेंट) ...

यदि आदेश का समर्थन नहीं किया जाता है तो गर्भपात एक पर सेट किया जाएगा। - यह संभव नहीं लगता।

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

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

बस अगर आप अभी तक डायग्नोस्टिक्स चलाने से नहीं थक रहे हैं ...

आप smartctl -t long /dev/sdaयह देखने के लिए फिर से कोशिश कर सकते हैं कि क्या यह SMART लॉग में कोई और त्रुटि उत्पन्न करता है, या आप इसे एक एक्स-फाइल के रूप में छोड़ सकते हैं ;) और फिर से हो सके यह देखने के लिए समय-समय पर SMART लॉग की जांच करें। किसी भी स्थिति में, यदि आप ड्राइव को बिना किसी रियलाइज किए या लंबित सेक्टर को साफ किए बिना उपयोग करना जारी रखते हैं, तो आप पहले से ही एक जोखिम ले रहे हैं।

चेकसमिंग फ़ाइल सिस्टम का उपयोग करें

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


अच्छा विचार है, मैं अभी कोशिश करूंगा।
इवान कोवेसेविक

1
167095 के उस बुरे सेक्टर के साथ यह कोशिश करने के बारे में क्या? :)
सप्ताह

नाहा कि बहुत उबाऊ है: डी। मैं सबसे पहले संदिग्ध क्षेत्र के साथ कोशिश करता हूं, निश्चित रूप से एक स्मार्ट सलाह, अगर ऐसा कुछ नहीं करता है तो मैं इसे पूरे मामले में बस चलाने दूंगा ...
इवान कोवेसेविक

@week है कि चाल करना चाहिए, लेकिन ऐसा लगता है कि वह बुरे क्षेत्र पर शून्यकरण में परेशानी कर रहा है इसलिए मैंने पूरी ड्राइव करने का सुझाव दिया है।
लूटने

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

5

बैड सेक्टर रीमैपिंग का लेख उपयोग किए गए एल्गोरिदम को देता है।

हार्ड डिस्क पर दोषों की दो सूचियाँ हैं:

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

इसलिए तथ्य यह है कि आपका बुरा क्षेत्र सामान्य क्षेत्र से परे 577121 क्षेत्र है, इसका मतलब यह नहीं है कि आपके पास 577121 बुरे क्षेत्र हैं, जब तक कि यह पी-सूची दोष नहीं है। एक जी-सूची दोष कहीं भी रखा जा सकता है, इसलिए यह पूरी तरह से संभव है कि फर्मवेयर ने इसे स्पेयर सेक्टर के स्थान के अंत में आवंटित किया है।

विकिपीडिया ज्ञात ATA स्मार्ट विशेषताओं से :

पुनर्आबंटित क्षेत्रों की गणना

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

मौजूदा लंबित क्षेत्र की गणना

"अस्थिर" सेक्टरों की गणना (अप्राप्य पढ़ने योग्य त्रुटियों के कारण, रीमेक होने की प्रतीक्षा)। यदि किसी अस्थिर क्षेत्र को बाद में सफलतापूर्वक पढ़ा जाता है, तो इस क्षेत्र का पुन: उपयोग किया जाता है और यह मान घट जाता है। एक सेक्टर पर त्रुटियों को पढ़ें क्षेत्र को तुरंत रीमैप नहीं किया जाएगा (क्योंकि सही मूल्य नहीं पढ़ा जा सकता है और इसलिए रीमैप का मूल्य ज्ञात नहीं है, और बाद में यह पठनीय भी हो सकता है); इसके बजाय, ड्राइव फर्मवेयर को याद है कि सेक्टर को रीमैप करने की आवश्यकता है, और अगली बार इसे लिखे जाने पर इसे रीमैप कर देगा।

इसलिए वास्तव में, लंबित त्रुटियों को रीमैप किए जाने की तुलना में बहुत बुरा है, क्योंकि रीमैप के लिए मूल सामग्री को पढ़ने से रोकने के लिए त्रुटि काफी कठिन है। वास्तव में, उस क्षेत्र की सामग्री शायद हमेशा के लिए खो जाती है।

दस्तावेज़ MHDD बहुत निम्न स्तर हार्ड डिस्क डायग्नोस्टिक टूल त्रुटि-कोड के रूप में बताता है:

UNC : data is uncorrectable
ABRT : command was aborted

इसलिए सेक्टर 167095 अचूक है और 235018779 तक पढ़ना / लिखना निरस्त कर दिया गया।

जैसा कि दोनों सेक्टरों ने लिखा है कि स्थिति को लंबित से हटाकर नहीं बदला है, मुझे लगता है कि प्रतिस्थापन क्षेत्र भी खराब है। मेरा सिद्धांत यह है कि सेक्टर 167095 को सेक्टर 235018779 में रीमेक किया गया था, लेकिन दुर्भाग्य से बाद वाला भी खराब है, और यह कि फर्मवेयर को पता नहीं है कि कैसे खराब स्पेयर सेक्टरों को फिर से तैयार करना है। परिणाम एक अचूक खराब क्षेत्र है।


अच्छा लेख, मैं निश्चित रूप से कुछ नया सीखा! हालाँकि यह अभी भी स्पष्ट नहीं करता है कि SMART लॉग्स में रिपोर्ट किए गए खराब सेक्टर की सूचना क्यों नहीं दी गई है, यह भी स्पेयर सेक्टर क्षेत्र में है और सामान्य उपयोग योग्य स्थान में नहीं है और क्यों लंबित सेक्टर काउंटर अभी भी 1 और वास्तविक सेक्टर काउंटर 0. है। यदि सब कुछ काम करना चाहिए इन दो काउंटरों को अपने मूल्यों को उलटना चाहिए।
इवान कोवेसेविक

1
ऊपर मेरा संपादन देखें।
18

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

1
केवल दो खराब क्षेत्रों के साथ एक बड़ी डिस्क जंक होने का गुण नहीं देती है। जैसे ही बैडब्लॉक सफल हुआ, उम्मीद है कि इसने उस क्षेत्र को खराब के रूप में चिह्नित किया। मैं इसके लिए लिनक्स को स्थापित करने की कोशिश करूंगा, लेकिन एक पूर्ण प्रारूप बनाऊंगा यदि आपका वितरण स्थापना के दौरान ऐसा कर सकता है। लेकिन अगर यह एक महत्वपूर्ण उत्पादन प्रणाली के लिए है, तो मैं डिस्क को बदल दूंगा, बस मामले में।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.