هل يمكن أن تنخفض البيانات على محركات الأقراص الثابتة دون تحذير حول الضرر؟
نحن جميعًا قلقون بشأن الحفاظ على سلامة بياناتنا وملفاتنا ، ولكن هل من الممكن أن تتضرر البيانات ويتم الوصول إليها من قبل مستخدم بدون إشعار أو تحذير من أي نوع بخصوص المشكلة؟ إن سؤال SuperUser Q & A اليوم لديه إجابة على سؤال القارئ القلق.
تأتي جلسة الأسئلة والأجوبة اليوم مقدمة من SuperUser-a subdivision of Stack Exchange ، وهي مجموعة مجتمعية مدفوعة من مواقع Q & A.
الصورة مجاملة للتعميم (فليكر).
السؤال
يريد قارئ SuperOser topo morto معرفة ما إذا كانت البيانات الموجودة على محركات الأقراص الثابتة يمكن أن تتحلل ويتم الوصول إليها دون تحذير بشأن الضرر:
هل من الممكن أن يتسبب التدهور المادي لمحرك الأقراص الثابت في "تغيير" محتويات الملف دون أن يلاحظ نظام التشغيل التغيير ويخطر المستخدم بذلك عند قراءة الملف؟ على سبيل المثال ، يمكن أن يتغير "p" (binary 01110000) في ملف نصي ASCII إلى "q" (binary 01110001) ، ثم عندما يفتح المستخدم الملف ، فإنهم يرون "q" دون علمهم بحدوث فشل.?
أنا مهتم بالإجابات المتعلقة FAT أو NTFS أو ReFS (إذا أحدثت فرقًا). أرغب في معرفة ما إذا كانت أنظمة التشغيل تحمي المستخدمين من ذلك ، أو إذا كان علينا التحقق من بياناتنا عن الفروق بين النسخ على مدار الوقت.
هل يمكن أن تتحلل البيانات الموجودة على محركات الأقراص الثابتة ويتم الوصول إليها دون تحذير بشأن الضرر?
الاجابة
مساهم SuperUser Guntram Blohm لديه إجابة لنا:
نعم ، هناك شيء يسمى بت العفن. ولكن لا ، لن يؤثر ذلك على مستخدم دون أن يلاحظه أحد.
عندما يكتب محرك الأقراص الثابتة قطاعًا إلى الأطباق ، فإنه لا يكتب البتات بنفس الطريقة التي يتم تخزينها بها في ذاكرة الوصول العشوائي ، بل يستخدم تشفيرًا للتأكد من عدم وجود تسلسلات من نفس البت التي تكون طويلة جدًا. كما أنه يضيف رموز ECC التي تسمح لها بإصلاح الأخطاء التي تؤثر على عدد قليل من البتات وكشف الأخطاء التي تؤثر على أكثر من عدد قليل من البتات.
عندما يقرأ القرص الصلب القطاع ، فإنه يتحقق من رموز ECC ويصلح البيانات إذا لزم الأمر (وإن أمكن). يعتمد ما يحدث بعد ذلك على ظروف البرنامج الثابت للقرص الصلب ، والذي يتأثر بتسمية محرك الأقراص.
- إذا كان من الممكن قراءة قطاع وليس له مشاكل في كود ECC ، فإنه يتم تمريره إلى نظام التشغيل.
- إذا كان من الممكن إصلاح قطاع ما بسهولة ، فقد تتم كتابة النسخة التي تم إصلاحها على القرص ، ثم قراءتها مرة أخرى ، ثم التحقق منها لتحديد ما إذا كان الخطأ عشوائيًا (أي الأشعة الكونية ، وما إلى ذلك) أو إذا كان هناك خطأ منهجي في الوسائط.
- إذا حدد محرك الأقراص الثابت وجود خطأ في الوسائط ، فقم بإعادة تخصيص القطاع.
- إذا لم يكن بالإمكان قراءة أي مقطع أو تصحيحه بعد بضع محاولات للقراءة (على محرك أقراص صلبة تم تعيينها على أنها محرك أقراص ثابتة RAID) ، فإن محرك الأقراص الثابتة سوف يتخلى عن ذلك ، ثم يعيد تخصيص القطاع ، ويخبر وحدة التحكم أن هناك مشكلة . يعتمد على وحدة تحكم RAID لإعادة بناء القطاع من أعضاء RAID الآخرين وكتابته مرة أخرى إلى محرك الأقراص الثابت الذي فشل ، والذي يقوم بتخزينه في القطاع المعاد تخصيصه (على أمل ألا يكون هناك مشكلة).
- إذا لم يكن بالإمكان قراءة أو تصحيح أي مقطع على القرص الصلب الخاص بجهاز سطح المكتب ، فسيقوم القرص الصلب بمزيد من المحاولات لقراءته. اعتمادًا على جودة محرك الأقراص الثابتة ، قد يتضمن ذلك إعادة وضع الرأس ، والتحقق مما إذا كانت هناك أي وحدات بت تقلب عند القراءة بشكل متكرر ، والتحقق من البتات الأضعف ، وبعض الأشياء الأخرى. إذا نجحت أي من هذه المحاولات ، فسيقوم القرص الصلب بإعادة تخصيص القطاع وإعادة كتابة البيانات التي تم إصلاحها.
يعد هذا أحد الفروق الرئيسية بين محركات الأقراص الثابتة التي يتم بيعها على أنها محركات أقراص ثابتة "سطح المكتب" أو "NAS / RAID" أو محركات الأقراص الثابتة "المراقبة بالفيديو". يمكن لمحرك أقراص RAID الثابت الاستسلام بسرعة وجعل وحدة التحكم تقوم بإصلاح القطاع لتجنب الكمون على جانب المستخدم. سيستمر محرك الأقراص الثابت على سطح المكتب في المحاولة مرارًا وتكرارًا لأن انتظار المستخدم لبضع ثوانٍ هو أفضل من إخباره بأن البيانات مفقودة. ويقدر محرك أقراص الفيديو الثابت معدلات البيانات الثابتة أكثر من استرداد الأخطاء حيث أن الإطار التالف لن يتم ملاحظته.
على أي حال ، فإن محرك الأقراص الصلبة سيعرف ما إذا كان هناك تعفن في البتات ، سوف يتعافى منه عادة ، وإذا لم يستطع ذلك ، فإنه سيخبر وحدة التحكم التي ستقوم بدورها بإخبار السائق الذي سيخبر نظام التشغيل. ثم ، الأمر متروك لنظام التشغيل لتقديم الخطأ للمستخدم والتصرف عليه. هذا هو السبب في أن cybernard يقول:
- لم أشهد أبداً خطأً أحادياً ، لكني رأيت الكثير من محركات الأقراص الصلبة حيث فشلت قطاعات بأكملها.
سيعرف محرك الأقراص الثابتة ما إذا كان هناك شيء خاطئ في قطاع ما ، ولكنه لن يعرف أي الأجزاء التي فشلت. سيتم القبض على بتة واحدة التي فشلت من قبل ECC.
الرجاء ملاحظة أن chkdsk وأنظمة الملفات التي تقوم بإصلاح نفسها تلقائيًا لا تتناول إصلاح البيانات داخل الملفات. وتستهدف هذه الفساد داخل بنية نظام الملفات نفسه ، مثل الاختلاف في حجم الملف بين إدخال الدليل وعدد الكتل المخصصة. ستكشف ميزة الاسترداد الذاتي لـ NTFS عن الأضرار الهيكلية وتمنعها من التأثير في بياناتك بشكل أكبر ، ولكنها لن تقوم بإصلاح أي بيانات متضررة بالفعل.
هناك ، بالطبع ، أسباب أخرى قد تتلف البيانات. على سبيل المثال ، قد يؤدي استخدام ذاكرة الوصول العشوائي غير الصحيحة على وحدة التحكم إلى تغيير البيانات قبل إرسالها إلى محرك الأقراص الثابتة. في هذه الحالة ، لن تقوم أي آلية على القرص الصلب باكتشاف البيانات أو إصلاحها ، وقد يكون هذا أحد الأسباب التي أدت إلى تلف بنية نظام الملفات. هناك أسباب أخرى تتضمن أخطاء البرامج ، أو انقطاع التيار الكهربائي أثناء الكتابة على القرص الصلب (على الرغم من أن هذا يتم التعامل معه عن طريق نظام الملفات) ، أو برامج تشغيل نظام الملفات السيئة (برنامج تشغيل NTFS على نظام التشغيل Linux المعطلة للقراءة فقط لفترة طويلة منذ أن تم إجراء هندسة عكسية لنظام NTFS ، غير موثقة ، ولم يثق المطورون برمزهم الخاص).
- كان لدي هذا السيناريو مرة واحدة حيث يقوم التطبيق بحفظ جميع ملفاته إلى خادمين مختلفين في مركزين بيانات مختلفين من أجل الاحتفاظ بنسخة عاملة من البيانات المتاحة في جميع الظروف. بعد بضعة أشهر ، لاحظنا أن حوالي 0.1 في المئة من جميع الملفات المنسوخة لم تتطابق مع مجموع فحص MD5 الذي يخزن التطبيق في قاعدة البيانات الخاصة به. اتضح أن يكون كابل الألياف الخاطئ بين الخادم وشبكة منطقة التخزين.
هذه الأسباب الأخرى هي لماذا تحتفظ بعض أنظمة الملفات ، مثل ZFS ، بمعلومات إضافية عن فحص الشيكات لاكتشاف الأخطاء. وهي مصممة لحمايتك من الكثير من الأشياء التي يمكن أن تسير على نحو خاطئ من تعفن البت.
هل لديك شيء تضيفه إلى الشرح؟ الصوت قبالة في التعليقات. هل ترغب في قراءة المزيد من الإجابات من مستخدمي Stack Exchange الآخرين المحترفين بالتكنولوجيا؟ تحقق من موضوع المناقشة الكامل هنا.
