هيتاشي يموتون بجد ، باش والمجازر التكنولوجية

تحذير: الحل الموضح في هذه المقالة ليس احترافيًا ، فقد يكون تم إنشاؤه على أساس سوء فهم بنية ومبادئ تشغيل محركات الأقراص الصلبة. تكرار الخطوات المذكورة أعلاه قد يضر بالجهاز.

لقد صادفت مؤخرًا مقالًا حول استخدام محركات الأقراص الصلبة القديمة ذات الكتل السيئة واعتقدت أن تجربتي قد تكون ممتعة أيضًا لشخص ما.

مرة واحدة ، طلب مني معارفه المساعدة في التعامل مع كمبيوتر محمول لم يتمكنوا من إعادة تثبيت Windows عليه. كان للحاسوب المحمول ، بناءً على المظهر ، حياة صعبة: الشقوق في العلبة ، الزوايا المنعكسة ، الحطام. من الواضح أن المشكلة تكمن في تلف القرص الصلب نتيجة للعديد من السكتات الدماغية ، والتي تم تأكيدها أيضًا من خلال تقنية ذكية: أكثر من 200 عملية استشعار G-500 ، 500 عدد قطاع مُعاد تخصيصه ، وما زال هناك في انتظار المراجعة. حسنًا ، الأشخاص ، بالطبع ، قمت بتثبيت SSD ، ونسخ المعلومات من المسمار في الصورة باستخدام الأمر:

dd if=/dev/sdb of=/media/hddimages/ht320.img bs=409600 conv=noerror,notrunc,sync 

هناك حاجة إلى المعلمات "conv = noerror ، notrunc ، sync" بحيث في حالة وجود أخطاء في قراءة قطاعات معينة ، تتم كتابة الأصفار على هذه العناوين في ملف الإخراج ، وتتم كتابة البيانات إلى مكانها دون تحيز.

يحدث أنه عند القراءة في كتل كبيرة (400 كيلو بايت) ، لا يقرأ القرص الكتلة بالكامل ، بينما لا يقرأ القطاع الأصغر قطاعًا واحدًا فقط. القطاعات هنا هي 4 كيلوبايت ، لذلك بعد مرور أول يوم ، إذا كانت هناك أخطاء في القراءة ، أحاول قراءة هذه الأقسام مرة أخرى في كتل 4 كيلوبايت:

 n=<>;dd if=/dev/sdb of=/media/hddimages/ht320.img bs=4096 conv=noerror,notrunc,sync skip=$n seek=$n count=100 

هناك حاجة إلى المعلمات تخطي والبحث حتى تبدأ القراءة والكتابة بنفس المسافة البادئة من بداية القرص. يتم أخذ المسافة البادئة نفسها من إخراج أول تنفيذ dd ، فقط لمطابقة حجم الكتلة ، اضرب الرقم في 100.

في بعض الأحيان ، عند الوصول إلى القطاعات السيئة ، تتجمد الأقراص لفترة طويلة ، لدرجة أن إعادة الاتصال فقط بالطاقة ويساعد منذ حوالي 5 سنوات على إنشاء مجمع برامجيات للأجهزة (مع متحكم دقيق حتى) لأتمتة قراءة الأقراص الصلبة السيئة عن طريق إعادة الاتصال التلقائي بالطاقة عدم وجود استجابة طويلة. كانت مثيرة للاهتمام ومسموح بها ، من خلال ربط الصعب ودخول الأمر ، بعد 10 أيام للحصول على الصورة الأكثر اكتمالا. لكن البطل التجريبي لهذه المقالة لم يعلق بشدة ، لذلك لم تكن هناك حاجة للحصول على عكاز ثقيل الموصوف.

لذلك ، تم النظر في القرص ، قمت بتثبيت جميع أقسام الصورة من خلال losetup مع إزاحة لبداية الأقسام من fdisk ، مضروبًا في حجم الكتلة المنطقية في mbr - 512 بايت ، وأنا أنسخ جميع البيانات إلى أشخاص على SSD جديد. إذا لم يتم تثبيت القرص أو تعذر قراءة العديد من الملفات ، فسوف أقوم بفتح الصورة باستخدام برنامج R-Studio واستعادتها من خلالها ، ولكن من الصورة نفسها.

لكن الثابت ، رغم تعرضه للضرب ، هو أمر مؤسف للتخلص منه ، لذلك قررت تنشيطه بطريقة أو بأخرى. من الناحية النظرية ، تقوم وحدة التحكم بالقرص بتمييز القطاعات على أنها تالفة وإعادة تعيين قطاعات النسخ الاحتياطي لعناوينها في حالة حدوث محاولات فاشلة متكررة للكتابة أو أخطاء في القراءة (غير قابلة للاسترداد) (باستخدام ECC).

للبدء ، أحاول مسح القرص (dd if = / dev / zero ...) وأقرأ بعد ذلك: السرعة غير مستقرة أيضًا ، يتجمد القرص وأحيانًا يحدث خطأ في الإدخال / الإخراج ، ولكن في معدل الذكاء يتزايد عدد مرات إعادة الانطلاق والتعليق. بعد عدة دورات ، لم يتغير الذكاء كثيرًا بشكل خاص ، ولم تنتقل المواضع المعلقة ، وتحدث الأخطاء في كل مرة في نفس الأماكن أو في مكان قريب جدًا. أحاول إعادة تعيين الخريطة يدويًا بقوة باستخدام الأمر "hdparm --make-bad-sector" ، لكن هذا لا يعمل على هذا النموذج وأدركت أن مجرد محو القراءة ، وكذلك قراءة الكتابة ، لن يكون بمقدورها إظهار جميع مجالات المشكلات. في الواقع ، إذا كانت البتة التالفة ، بصرف النظر عما حاولوا الكتابة إليه ، من المرجح أن تقرأ كـ "1" ، فعند الكتابة إليها ، "1" ، ستتم القراءة التالية دون أخطاء ، لكن عند كتابة نمط مختلف ، هناك تناقضات كافية بحيث تفشل ECC ويحدث خطأ قراءة لا يمكن إصلاحه ، وبعد عدة حالات من هذا القبيل ، تلقى القطاع حالة "سيئة". بالمناسبة ، يمكن فرض القيمة المسجلة على توزيع البتات التالفة بحيث تفي القيمة غير الصحيحة بالقراءة إلى ECC. لذلك ، لتحقيق أقصى قدر من تحديد جميع القطاعات السيئة ، تحتاج إلى إنشاء نمط عشوائي نسبيا ، والكتابة إلى القرص ، وقراءة ومقارنة القيمة. هناك أيضا قطاعات غير مستقرة ، والتي تغير قيمها تدريجيا مع مرور الوقت أو بعد معالجة جيرانها.

بالنظر إلى كل ما سبق ، قررت تنفيذ الاستراتيجية التالية في برنامج نصي bash:

• نحن نولد نمطًا عشوائيًا وننظر في المجموع الاختباري له ؛
• نقرأ الذكية.
• اكتب قرصًا في الأصفار ؛
• قراءة القرص ؛
• نكتب القرص بنمط عشوائي مع قراءة الكتلة المسجلة فقط ومقارنة مبلغ الشيك الخاص به ؛
• نقرأ القرص بعد التسجيل الكامل ، والتحقق من مبالغ الاختيار من كل كتلة.
• نقرأ الذكية.
• اختبار الذات؛
• غوتو 1.

نستمر في هذا الطريق إلى أن تتوقف قطاعات القراءة الخاطئة وتتوقف أخطاء IO عن الحدوث أو حتى تتم تغطية المسمار بالكامل. بالمناسبة ، كيف يعمل الاختبار الذاتي لهذا النموذج من القرص ، لا أستطيع أن أتخيل ؛ لا أعرف كم من الوقت يختلف عن short'a (على الرغم من أنه يعمل لفترة طويلة مع السطح بالكامل ، وقصير - يركز على الإحصائيات التي تم جمعها مسبقًا ، كما هو الحال في التنسيق: ممتلئ وسريع). آمل أن يشجع هذا المسمار على الأخذ في الاعتبار التجربة الحديثة وإعادة رسم خريطة القطاعات السيئة.

عندما انتهيت من كتابة البرنامج النصي bash ، قمت بتشغيله وفحصت النتائج في اليوم التالي - رأيت أن عملية التحقق بطيئة جدًا ، بينما لا يصل حمل المعالج إلى 60٪ على أي لب. هذا جعلني ألعب مع حجم الكتلة ، واختبر خوارزميات تجزئة مختلفة للاختبارات ، وجرب التحقق المباشر من الفرق ، ولا أقارن الاختبارات ، لكن لم أستطع الوصول إلى سرعات المعالجة التي تزيد عن 12 ميجابايت في الثانية. كنتيجة لذلك ، توقفت عن مقارنة الكتل 400 كيلو بايت مع فرق ، وأنا أحسب المجموع الاختباري فقط إذا كان هناك عدم تطابق فقط للتحليل اللاحق للسجل.

 #!/bin/bash #    hddtest.sh diskdev logfile [blocksize] diskdev="$1"; test_log="$2"; #"~/work/hdd/test.log" blsz="${409600:-$3}"; n="1"; sizebyte=`fdisk -l "$diskdev"|grep "Disk $diskdev:"|cut -d" " -f5`; let sizebl=$sizebyte/$blsz; #"781428" for 320GB while true;do echo "starting iteration $n"; dd if=/dev/urandom of=fil bs="$blsz" count=1; md5ok=`md5sum fil|cut -d" " -f1`; cp fil fil_"$n"; echo "random pattern md5sum $md5ok">>"$test_log"; smartctl -A "$diskdev">>"$test_log"; echo "filling disk with zeroes">>"$test_log"; dd if=/dev/zero of="$diskdev" bs="$blsz"; #count="$sizebl"; echo "disk is wiped fully">>"$test_log"; dd of=/dev/null if="$diskdev" bs="$blsz"; # count="$sizebl"; echo "writing disk with fil-pattern">>"$test_log"; i="0"; while [ "$i" -le "$sizebl" ]; do #echo "writing fil: $i ">>"$test_log"; dd if=fil of="$diskdev" bs="$blsz" seek="$i"; dd if=/dev/null of=tst; dd if="$diskdev" bs="$blsz" of=tst skip="$i" count=1 conv=notrunc,noerror,sync; #md5tst=`md5sum tst|cut -d" " -f1`; verf=`diff -s fil tst|sed 's/.* //g'`; if [ "$verf" != "identical" ]; #if [ "$md5ok" != "$md5tst" ]; then md5tst=`md5sum tst|cut -d" " -f1`; echo "$i : md5 $md5tst is not ok">>"$test_log"; cp tst tst_"$n"_"$i"; fi; let i="$i"+1; done; echo "test of full writed with fil-pattern disk">>"$test_log"; i="0"; while [ "$i" -le "$sizebl" ]; do #echo "after writing test: $i">>"$test_log"; dd if=/dev/null of=tst; dd if="$diskdev" bs="$blsz" of=tst skip="$i" count=1 conv=notrunc,noerror,sync; #md5tst=`md5sum tst|cut -d" " -f1`; verf=`diff -s fil tst|sed 's/.* //g'`; if [ "$verf" != "identical" ]; #if [ "$md5ok" != "$md5tst" ]; then md5tst=`md5sum tst|cut -d" " -f1`; echo "$i : md5 $md5tst is not ok">>"$test_log"; cp tst tst_"$n"_"$i"; fi; let i="$i"+1; done; smartctl -A "$diskdev" >>"$test_log"; smartctl -t long "$diskdev">>"$test_log"; sleep 5000; #smartctl -t short "$diskdev">>"$test_log"; #sleep 240; let n="$n"+1; done 

كما أظهرت السجلات بعد التنفيذ المتكرر للبرنامج النصي ، كانت جميع القطاعات السيئة في أول 13 غيغابايت من القرص ، وكان هناك العديد من "بؤر" من الهزيمة (ربما ، عندما ضرب الرأس ، خدش السطح والخدش). في آخر 15 تشغيلًا ، لم يشاهد القرص أي قطاعات مشبوهة (معلقة) ، تم إعادة تعيين كل شيء بالفعل ، ولكن في مكان ما في منتصف الـ 13 جيجا بايت ، تم قراءة كتلة واحدة أو كتل غير بعيدة عنه بشكل غير صحيح إلى عناوين مختلفة. علاوة على ذلك ، يمكن اعتبار كتلة واحدة غير صحيحة لدورتين على التوالي ، ثم مرتين بشكل صحيح ومرة ​​أخرى بشكل غير صحيح. لذلك كان للقبض على آخر 10 قطاعات سيئة عملية طويلة. وكان ما مجموعه 1268 القطاعات إعادة رسم خريطة! وفي النهاية ، انتظرتني مفاجأة: عندما كان كل شيء يعمل بالفعل بشكل مستقر ، وبعد الاختبار الذاتي التالي ، أصبحت المعلمة "إعادة تخصيص القطاع" "0" وفقط عدد الأحداث المعاد تخصيصها وسجلات الأخطاء الخمسة الأخيرة (مع العنوان والوقت من بدء العمل) المخزنة في المجلة.

على الرغم من التشغيل المستقر ، قررت مع ذلك تقليل التفاعل مع المنطقة المتضررة حتى لا تجرح الرأس حول المخالفات المحتملة في الأماكن ذات الأسطح التالفة للألواح ، ولم أكن أرغب في الوثوق بالقطاعات المحلية على المدى الطويل. لقد تراجعت قليلاً بهامش وأنشأت قسمًا يبدأ بالجيجابايت الخامسة عشرة. وكما أظهر الوقت ، فإن القرص في حالة جيدة وقد عمل بثبات في جهاز كمبيوتر محمول يمكن ارتداؤه لمدة 10 أشهر.

على الرغم من أنه من المستحيل الوثوق الكامل بالقرص المستعاد والجدوى الاقتصادية للمشروع مشكوك فيها ، إلا أن النتيجة في بعض الأحيان ليست سوى إضافة لطيفة إلى الطريقة الجيدة.