قبل أسبوعين ، تم اكتشاف خطأ في إصدار Linux 5.1 kernel الذي أدى إلى فقد البيانات على SSD. في الآونة الأخيرة ،
أصدر المطورون تصحيح تصحيح Linux 5.1.5 ، الذي ملأ "فجوة".
نناقش ما كان السبب.
/ Unsplash / جلين كاريما علة
في بداية العام ، قام المطورون بعدد من التغييرات على Linux 5.1 kernel. بعد ذلك ، في الأنظمة ذات SSDs من Samsung التي تستخدم تشفير dm-crypt / LUKS مع مخطط الجهاز / LVM ،
بدأ ظهور خطأ ، مما أدى إلى فقدان البيانات. لكن المشكلة
أصبحت معروفة فقط في منتصف شهر مايو - في ذلك الوقت بدأوا في
مناقشتها بنشاط
في المنتديات المواضيعية .
شخصان على الأقل على دراية بالخطأ
معروفان: عضو LKML Michael Laß ، الذي
أبلغ عن المشكلة لأول مرة ،
ومستخدم ArchLinux.
قام Michael
بتشغيل الأمر fstrim ، والذي يخبر محرك الأقراص أي كتل البيانات لم تعد قيد الاستخدام لوحدة تخزين btrfs المثبتة. بعد أن تلقى رسائل النظام التالية:
attempt to access beyond end of device sda1: rw=16387, want=252755893, limit=250067632 BTRFS warning (device dm-5): failed to trim 1 device(s), last error -5 BTRFS warning (device dm-5): csum failed root 257 ino 16634085 off 21504884736 csum 0xd47cc2a2 expected csum 0xcebd791b mirror 1
بعد ذلك ، اكتشف أن حجم btrfs تالف وتم إتلاف وحدات التخزين المنطقية المتبقية على الجهاز الفعلي.
في حالة مستخدم ArchLinux ، أثرت المشكلة على حماية تشفير LUKS. بعد إعادة تشغيل نظام التشغيل وتشغيل fstrim ، تبين أن رؤوس LUKS (والتي تستخدم للبحث عن وحدات التخزين) غير قابلة للقراءة ، والتي لم تسمح بتشفير البيانات المشفرة.
ما السبب
كانت المشكلة هي النظام الفرعي
لمخطط الجهاز (DM) ، وكانت مهمته إنشاء أجهزة كتلة افتراضية. يتم استخدامه فقط لتطبيق إدارة التخزين المنطقي LVM ، RAID للبرنامج ، ونظام تشفير القرص dm-crypt.
"قام فريق fstrim بتمييز عدد كبير جدًا من الكتل في وقت واحد دون مراعاة الحد الأقصى للقيمة____ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ ونتيجة لذلك ، تم تحرير شرائح الذاكرة التي لا تزال قيد الاستخدام "، تعليق سيرجي بلكين ، رئيس قسم التطوير 1cloud.ru . "نظرًا لأن الخطأ كان متعلقًا بمخطط الجهاز ، من الناحية النظرية ، يمكن أن يحدث فقدان البيانات على أي نظام ملفات."
بقعة
أصدر مطورو Kernel تصحيحًا لهذا الخطأ في أواخر مايو. تم
تغيير أربعة أسطر فقط في ملف Drivers / md / dm.c. تم إجراء التغييرات المقابلة أيضًا على Linux 5.2 kernel المرتقب (يتم تمييز الخطوط المضافة والمحذوفة بعلامة "+" و "-" ، على التوالي):
@@ -1467,7 +1467,7 @@ static unsigned get_num_write_zeroes_bios(struct dm_target *ti) static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *ti, unsigned num_bios) { - unsigned len = ci->sector_count; + unsigned len; @@ -1478,6 +1478,8 @@ static int __send_changing_extent_only(struct clone_info *ci, struct dm_target * if (!num_bios) return -EOPNOTSUPP; + len = min((sector_t)ci->sector_count, max_io_len_target_boundary(ci->sector, ti)); + __send_duplicate_bios(ci, ti, num_bios, &len); ci->sector += len;
تم تطبيق التصحيح بالفعل من قبل مطوري توزيع
ArchLinux / Manjaro و
Fedora .
لم يؤثر توزيع Ubuntu
على الخطأ ، حيث إنه لم يتم ترجمته إلى إصدار Linux 5.1 kernel.
/ فليكر / أندي ميلتون / CC BY-SAيمكنك القضاء على الموقف مع فقدان البيانات دون تثبيت التصحيح. يكفي تعطيل خدمة fstrim.service / timer باستخدام الأوامر:
systemctl disable fstrim.timer systemctl stop fstrim.timer
خيار آخر هو إعادة تسمية fstrim القابل للتنفيذ أو إزالة إشارة تجاهل عند تركيب fstab. يمكنك أيضًا إيقاف تشغيل السماح بالتجاهل في LUKS عبر dmsetup. ومع ذلك ، كل هذه الأساليب
ليست أكثر من مؤقتة ولا تحل جوهر المشكلة.
ليست المرة الأولى
ليست هذه هي المرة الأولى التي يؤدي فيها الالتزام في kernel Linux إلى حالات تلف في الذاكرة.
حدثت قصة مماثلة في إصدار Linux 4.19 - ثم تم إلقاء اللوم على برامج جدولة I / O لـ BLK-MQ. تم توضيح المشكلة عند إنشاء kernel باستخدام الخيار CONFIG_SCSI_MQ_DEFAULT = y ، بشكل افتراضي. في بعض الحالات ، تلف بيانات وحدة التخزين.
sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107 sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107
في معظم الأحيان ، تجلت المشكلة في EXT4 ، ولكن من الناحية النظرية يمكن أن تؤثر على أنظمة الملفات الأخرى.
ثم
أعد أحد مشرفي النواة
إصلاحًا صغيرًا لحل المشكلة. ومع ذلك ، تم اكتشاف الخطأ نفسه لاحقًا في إصدار Linux 4.20. كان من الممكن أخيرًا
التخلص منه في نهاية ديسمبر 2018 بتحديث عالمي جديد.
مواردنا ومصادرنا الإضافية:
ملف النسخ الاحتياطي: كيف تكون في مأمن من فقدان البيانات
تقليل المخاطر: كيف لا تفقد بياناتك
النسخ الاحتياطي والاسترداد: تدفق وإلغاء البيانات المكررة الذكية ، لقطات والتخزين الثانوي
كيفية توفير المال باستخدام واجهة برمجة التطبيقات
DevOps في خدمة سحابية باستخدام 1cloud.ru كمثال
1cloud تطور العمارة السحابية
كيف نعمل: الخلاصة 1cloud
هجمات محتملة على HTTPS وطرق الحماية ضدها