وقتی ۸ بیت، یک ترابایت رو به زانو درمی‌آره!

خطاهای پراکندهٔ input/output، خراب شدن پرونده‌های چند گیگابایتی و حتی چند بار read-only شدن فایل‌سیستم حین کار… هیچ‌کدومو جدی نگرفتم؛ تا این‌که بالاخره کار به جایی رسید که btrfs دیگه سوار نشد و رایانه بالا نیومد! اول به خود دیسک اس‌اس‌دی و کابل ساتا شک کردم، ولی یه‌هو یادم افتاد که حافظه این سیستم از همون قدیم مشکل داشت. دیگه گفتم بهتره به‌جای حدس زدن، این‌بار قشنگ بررسیش کنم.

با یه SystemRescue زنده اومدم بالا و memtest86+ رو اجرا کردم. نتیجه عملاً فاجعه بود: حدود ۷۰۰-۸۰۰ خطا فقط توی یک pass! با قیمت‌های فعلی هم که اصلاً امکان تعویض RAM وجود نداره. پس دنبال این گشتم که ببینم می‌شه همینو یه‌جوری نگهش داشت و فقط قسمت آسیب‌دیده‌شو کنار گذاشت؟

برای پیدا کردن دقیق ناحیه مخرب، گذاشتم چند دور دیگه هم آزمایش کنه تا شانس اشتباه بیاد پایین. تست‌های ۰، ۷ و ۱۰ رو هم خاموش کردم، چون برای این منظور بهشون نیازی نبود و فقط سرعت بررسی رو پایین می‌آوردن. بعد از حدود ۴–۵ دور، نزدیک به ۲۵۰۰ خطا ثبت شده بود؛ اما نکتهٔ جالب‌ترش این بود که همهٔ این خطاها روی فقط ۸ بیت مشخص اتفاق افتاده بودن!

۸ بیت در برابر ۱۶ گیگابایت تقریباً هیچی نیست، ولی همین خرابی کوچک کافی بود تا داده‌هایی که رایانه موقتاً توی حافظه نگه می‌داره آسیب ببینن و بعداً راهشون رو به دیسک باز کنن،‌ حتی با وجود btrfs checksum!

حالا باید کاری می‌کردم که لینوکس دیگه از اون قسمت استفاده نکنه. ازون‌جایی که کوچک‌ترین واحدی که می‌شه در این سطح از حافظه کنار گذاشت یک صفحه چهار کیلوبایتیه، نشونی محدودهٔ آسیب‌دیده رو پیدا کردم و خروجی badramی که خود memtest86+ داده بودو گذاشتم تو تنظیمات GRUB:

badram 0x000000036b642d20,0xfffffffffffffff8

این خط دقیقاً برای همین منظور کاربرد داره و به گراب می‌گه این بخش از آدرس فضای RAM رو نده به سیستم‌عامل. خلاصه بکاپی که داشتم رو روی یه btrfs تازه برگردوندم و آرچ عزیزم دوباره بالا اومد. از اون موقع هم دیگه خبری از I/O error نبوده تا حالا (:

avid@avid:~$ sudo cat /proc/iomem | grep -i '36b64'

100000000-36b641fff : System RAM

36b642000-36b642fff : Unusable memory

36b643000-46effffff : System RAM