عندما يكتب برنامج بايثون ملفًا، فإنّ استدعاء هذه الدالة   ؛ بل هو مجرد إقرار بالاستلام. بصفتنا مطورين، نعتمد على تجريدات عالية المستوى لإخفاء تعقيدات الأجهزة. نكتب شيفرةً تبدو حتميةً وفورية، غالبًا ما نفترض أن استدعاء دالة ناجحًا يُعادل ثباتًا ماديًا. لا يضمن التخزين  فكر في مقتطف Python البسيط هذا الذي يؤدي دورًا في نظام معالجة المعاملات:    عندما ذلك  transaction_id = "TXN-987654321" # Open a transaction log in text mode with open("/var/log/transactions.log", "a") as log_file: # Write the commitment record log_file.write(f"COMMIT: {transaction_id}\n") print("Transaction recorded") transaction_id = "TXN-987654321" # Open a transaction log in text mode with open("/var/log/transactions.log", "a") as log_file: # Write the commitment record log_file.write(f"COMMIT: {transaction_id}\n") print("Transaction recorded")  بعد تنفيذ عبارة   ، يُستأنف التطبيق عمله، مُفترضًا أن البيانات آمنة. مع ذلك، لم تصل البيانات إلى القرص، بل لم تصل حتى إلى نظام الملفات. لقد بدأ فقط سباق تتابع مُعقد عبر ست طبقات مُتمايزة من التجريد، لكل منها مخازن مؤقتة وأهداف معمارية خاصة بها. print  في هذه المقالة، سوف نصف دورة الحياة الفنية لحمولة البيانات هذه، أي السلسلة   أثناء انتقالها من مساحة مستخدم Python إلى السيليكون الخاص بـ SSD. "COMMIT: TXN-987654321\n"  [الطبقة 1]: مساحة المستخدم (Python & Libc)  المخزن المؤقت للتطبيق  تبدأ رحلتنا في ذاكرة عملية مُفسّر بايثون. عند استدعاء   على ملف مفتوح في وضع النص، لا يستدعي بايثون عادةً استدعاء نظام فورًا. تُعد عمليات تبديل السياق إلى النواة مُكلفة. بدلاً من ذلك، يستخدم بايثون مخزنًا مؤقتًا لمساحة المستخدم لتجميع البيانات. حجم هذا المخزن المؤقت افتراضيًا 8 كيلوبايت، وهو مُختار خصيصًا ليتوافق مع حجم صفحة ذاكرة نظام التشغيل الأساسي. file.write()  توجد حمولة بياناتنا في ذاكرة الوصول العشوائي (RAM) هذه. وهي مملوكة بالكامل لعملية بايثون. إذا توقف التطبيق فجأةً، ربما بسبب إشارة   أو خطأ في التجزئة، تُفقد البيانات فورًا. لم تُخزن في ذاكرة التطبيق. SIGKILL  التدفق وتغليف Libc  تُنهي عبارة   وتُفعّل أمر   تلقائيًا. هذا يُفعّل لاحقًا أمر   . يُخرج بايثون هذه البيانات ويُمرّر الحمولة إلى مكتبة C القياسية للنظام، مثل   على لينكس. تُمثّل   الواجهة القياسية للنواة. بينما تُدير دوال C، مثل   مخازن مساحة المستخدم الخاصة بها، فإن عملية التنظيف في بايثون عادةً ما تستدعي     ذات المستوى الأدنى مباشرةً. تُعدّ   سجلات وحدة المعالجة المركزية برقم واصف الملف، ومؤشر المخزن المؤقت، وطول الحمولة. ثم تُنفّذ تعليمة وحدة المعالجة المركزية، مثل   على معماريات x86-64، لحصرها في النواة. with .close() .flush() glibc libc fwrite دالة write(2) libc SYSCALL  في هذه المرحلة، نعبر الحدود من مساحة المستخدم إلى مساحة النواة.  [الطبقة 2]: حدود النواة (VFS)  ينتقل المعالج إلى الوضع ذي الامتيازات. تتولى نواة لينكس معالجة المقاطعة، وتتحقق من سجلات المعالج، وتحدد طلب الكتابة إلى واصف ملف. ثم تُسلم الطلب إلى   . يعمل نظام الملفات الافتراضي كطبقة توحيد للنواة، حيث يوفر واجهة برمجة تطبيقات متسقة للنظام، بغض النظر عما إذا كان التخزين الأساسي Ext4 أو XFS أو NFS أو قرص ذاكرة وصول عشوائي (RAM). نظام الملفات الافتراضي (VFS)  يُجري نظام الملفات الافتراضي (VFS) عمليات تحقق أولية من الصلاحية، مثل التحقق من الأذونات وحالة واصف الملف. ثم يستخدم واصف الملف لتحديد برنامج تشغيل نظام الملفات المسؤول عن المسار، وهو في هذه الحالة Ext4. يستدعي نظام الملفات الافتراضي عملية الكتابة الخاصة بهذا البرنامج.  [الطبقة 3]: ذاكرة التخزين المؤقت للصفحة (الإدخال/الإخراج المتفائل)  لقد وصلنا إلى مركز الأداء لمجموعة تخزين Linux:   . Page Cache  في لينكس، يتم   . عندما يستقبل برنامج تشغيل Ext4 طلب الكتابة، فإنه عادةً لا يبدأ اتصالاً فورياً بالقرص. بدلاً من ذلك، يستعد للكتابة في ذاكرة التخزين المؤقت للصفحات. ذاكرة التخزين المؤقت للصفحات هي قسم من ذاكرة الوصول العشوائي (RAM) للنظام   . تجدر الإشارة إلى أن Ext4 يُفوض عادةً عمليات الذاكرة المتعلقة بذاكرة التخزين المؤقت للصفحات إلى نظام إدارة ذاكرة النواة العام. ما يحدث بعد ذلك هو: تعيين إدخال/إخراج الملفات بشكل أساسي على الذاكرة مخصص لتخزين بيانات الملفات مؤقتاً  تُدير النواة الذاكرة في وحدات ذات حجم ثابت تُسمى   (عادةً 4 كيلوبايت في إعدادات لينكس القياسية). ولأن حمولة سجل المعاملات لدينا صغيرة (   )، فإنها تتوزع بالكامل ضمن صفحة واحدة. تُخصص النواة (أو تُحدد موقع) صفحة ذاكرة الوصول العشوائي (RAM) بحجم 4 كيلوبايت التي تُطابق الإزاحة الحالية للملف. الصفحات "COMMIT: TXN-987654321\n"  يقوم بنسخ حمولة البيانات إلى صفحة الذاكرة هذه.  يُعَلَّم هذه الصفحة بأنها   . تعني هذه الصفحة المتسخة أن البيانات في ذاكرة الوصول العشوائي (RAM) أحدث من البيانات الموجودة على وحدة التخزين الدائمة. "متسخة"    بمجرد نسخ البيانات إلى ذاكرة الوصول العشوائي (RAM)، تُعيد نداءات النظام     إلى   ، والتي تُعيد بدورها إلى بايثون. والأهم من ذلك، يستقبل التطبيق إشارة نجاح   أي إدخال/إخراج فعلي. تُعطي النواة   ، مما يُؤجل عملية القرص المُكلفة إلى عملية خلفية. البيانات حاليًا عُرضة لخطر تعطل النواة أو انقطاع التيار الكهربائي. الإرجاع: write(2) SUCCESS libc قبل الأولوية للإنتاجية وزمن الوصول على الاستمرار الفوري  [الطبقة 4]: نظام الملفات (Ext4 و JBD2)  قد تبقى البيانات في ذاكرة التخزين المؤقت للصفحات لفترة طويلة. تسمح إعدادات لينكس الافتراضية للصفحات الملوثة بالبقاء في ذاكرة الوصول العشوائي (RAM) لمدة تصل إلى 30 ثانية. في النهاية، يبدأ مؤشر ترابط نواة الخلفية عملية الكتابة العكسية لتنظيف هذه الصفحات الملوثة. يجب على   الآن الاحتفاظ بالبيانات. كما يجب عليه تحديث البيانات الوصفية المرتبطة بها، مثل حجم الملف ومؤشرات الكتل المادية على القرص. توجد هياكل البيانات الوصفية هذه في البداية فقط في ذاكرة النظام. ولمنع التلف أثناء التعطل، يستخدم Ext4 تقنية تُسمى التسجيل. نظام ملفات Ext4  قبل أن يُحدّث نظام الملفات بنية الملف بشكل دائم، يتفاعل Ext4 مع طبقة التسجيل الخاصة به، وهي   . يعمل Ext4 عادةً في وضع يُسمى "تسجيل البيانات المُرتّب". يُنظّم العملية بإرسال طلبات كتابة مُختلفة إلى طبقة التسجيل (الطبقة 5 - القسم التالي) بتسلسل مُحدّد. JBD2 (جهاز تسجيل البيانات)    . أولًا، يُرسل Ext4 طلبًا لكتابة محتوى البيانات الفعلي إلى موقعه النهائي على القرص. هذا يضمن احتواء كتل التخزين على معلومات صحيحة قبل أن تشير إليها أي مؤشرات بيانات وصفية. الخطوة الأولى: كتابة البيانات    . بعد انتهاء كتابة البيانات، يُرسل JBD2 طلب كتابة للبيانات الوصفية. ويكتب وصفًا للتغييرات في مخزن مؤقت دائري محجوز على القرص يُسمى السجل. يُعد هذا الإقرار بمثابة "إقرار" بتحديث بنية الملف بفعالية. الخطوة الثانية: إقرار السجل    . أخيرًا، يُنقِل نظام الملفات البيانات الوصفية المُعدَّلة من ذاكرة النظام إلى مكانها الدائم في جداول العقد على القرص. في حال تعطل النظام قبل هذه الخطوة، يُمكن لنظام التشغيل إعادة تشغيل السجل لاستعادة نظام الملفات إلى حالته الطبيعية. الخطوة 3: نقطة التفتيش  [الطبقة 5]: طبقة الكتلة ومجدول الإدخال/الإخراج  يُجمّع نظام الملفات بياناته المُعلّقة في بنية تُعرف باسم "   /الإخراج" (Block I/O). ثم يُرسِل هذه البنية إلى   . تعمل طبقة الكتلة كوحدة تحكم في حركة البيانات لنظام التخزين الفرعي. تُحسّن هذه الطبقة تدفق الطلبات قبل وصولها إلى الجهاز باستخدام   ، مثل MQ-Deadline أو BFQ. إذا كان النظام مُثقلاً بآلاف طلبات الكتابة الصغيرة والعشوائية، فإن المُجدوِل يعترضها لتحسين الكفاءة. وعادةً ما يُنفّذ عمليتين رئيسيتين. bio طبقة الكتلة مُجدوِل الإدخال/الإخراج    . يحاول المُجدول دمج الطلبات المتجاورة في عمليات أقل حجمًا وأكبر. بدمج عدة عمليات كتابة صغيرة تستهدف قطاعات متجاورة على القرص، يُقلل النظام عدد الأوامر الفردية التي يجب إرسالها إلى الجهاز. دمج الطلبات    . يُعيد المُجدول ترتيب قائمة الانتظار أيضًا. ويُعطي الأولوية للطلبات لزيادة إنتاجية الجهاز أو لضمان العدالة بين العمليات الجارية المختلفة. إعادة ترتيب الطلبات  بمجرد أن يُنظّم المُجدول قائمة الانتظار، يُمرّر الطلب إلى مُشغّل الجهاز المُحدّد، مثل   . يُترجم هذا المُشغّل طلب الكتلة العام إلى البروتوكول المُحدّد الذي يتطلّبه الجهاز، مثل مجموعة أوامر NVMe المُرسَلة عبر   . مُشغّل NVMe ناقل PCIe  [الطبقة 6]: الأجهزة (وحدة التحكم SSD)  تمر الحمولة عبر ناقل PCIe وتصل إلى قرص SSD. ومع ذلك، حتى داخل الجهاز، يلعب التخزين المؤقت دورًا حاسمًا. تعمل أقراص SSD الحديثة للمؤسسات كأجهزة كمبيوتر متخصصة، حيث تُشغّل برامج ثابتة خاصة بها على معالجات ARM متعددة الأنوية لإدارة العمليات الفيزيائية المعقدة لتخزين البيانات.    . ذاكرة التخزين المؤقتة DRAM والإقرار  لإخفاء زمن وصول ذاكرة فلاش NAND، البطيء في الكتابة مقارنةً بالقراءة، يقبل مُتحكم SSD البيانات في البداية في ذاكرة التخزين المؤقت DRAM الداخلية الخاصة به. بمجرد وصول البيانات إلى هذه الذاكرة، يُرسل المُتحكم إشعارًا إلى نظام التشغيل يُفيد بانتهاء عملية الكتابة. في هذه اللحظة الدقيقة،   . تُحفظ على لوحة الدائرة المطبوعة للمحرك بدلاً من اللوحة الأم للخادم. تحتوي محركات الأقراص عالية الأداء للشركات على مُكثفات لتفريغ ذاكرة التخزين المؤقت هذه عند انقطاع التيار الكهربائي المفاجئ، ولكن غالبًا ما تفتقر محركات الأقراص الاستهلاكية إلى هذه الحماية. تبقى البيانات في الذاكرة المؤقتة   الترجمة الفورية والمحو  تتولى الآن طبقة ترجمة الفلاش (FTL) في محرك أقراص الحالة الصلبة (SSD) زمام الأمور. ولأن ذاكرة فلاش NAND لا يمكن الكتابة فوقها مباشرةً، يجب مسحها على دفعات كبيرة أولًا. تحدد طبقة FTL الموقع المادي الأمثل للبيانات لضمان تساوي التآكل على القرص، وهي عملية تُعرف بتسوية التآكل.   التخزين المادي  أخيرًا، يُطبّق المُتحكّم جهدًا على الترانزستورات في شريحة NAND. يُغيّر هذا حالتها الفيزيائية لتمثيل البيانات الثنائية.  فقط بعد هذا التحول المادي تصبح   .  البيانات دائمة حقًا  الخاتمة: فهم عقد المتانة  تُبرز رحلة الكتابة التوازنَ الواضح الذي تُجريه أنظمة التشغيل بين الأداء والسلامة. فمن خلال السماح للطبقات بتخزين العمل مؤقتًا وتأجيله، تُحقق الأنظمة إنتاجية عالية، إلا أن تعريف "الكتابة" يصبح غير واضح. فإذا كان التطبيق يتطلب متانة بيانات صارمة عند اكتماله، حيث يكون فقدان البيانات غير مقبول، فلا يُمكن للمطورين الاعتماد على السلوك الافتراضي لاستدعاء دالة   في طبقة التطبيق. write()  لضمان استمرارية العمل، يجب اختراق طبقات التجريد هذه صراحةً باستخدام   . يستدعي هذا   في بايثون نداء نظام   (في أنظمة لينكس) الذي يُجبر على مسح الصفحات غير المرغوب فيها في نظام الملفات، ويُلزم السجل، ويُرسل كتلة الإدخال/الإخراج، ويُصدر أمر "مسح ذاكرة التخزين المؤقت" القياسي إلى وحدة تحكم التخزين، مطالبًا الجهاز بإفراغ مخازنه المؤقتة المتقلبة على ذاكرة NAND. تنتهي الرحلة فعليًا فقط بعودة   . os.fsync(fd) النداء fsync fsync

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

تشريح عملية الكتابة

About Author

تعليقات

شنق العلامات

تم تقديم هذه المقالة في

Related Stories

How to Use No-Code Machine Learning to Optimize your HackerNoon Articles

Top Ecommerce Development Companies

Best Mobile App Development Companies

Top iOS & iPhone Mobile App Development Companies

How to Use No-Code Machine Learning to Optimize your HackerNoon Articles

Top Ecommerce Development Companies

Best Mobile App Development Companies

Top iOS & iPhone Mobile App Development Companies

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps