الداتا اللي مابتضيعش
الـ RAM بتتمسح أول ما الكهربا تقطع. فأي حاجة لازم تفضل لازم تتكتب على ديسك، والديسك بطيء ومعقد ومليان تفاصيل. الدرس ده بيوريك نظام التشغيل بيخبّي كل ده ورا فكرة بسيطة اسمها "ملف"، وإيه اللي بيحصل فعلاً بين ما تكتب في ملف ولحد ما يوصل الديسك.
- تفهم ليه الـ Persistence محتاجة ديسك ونظام ملفات
- تعرف ليه نظام التشغيل مش بيعمل نسخة افتراضية من الديسك لكل برنامج
- تتابع رحلة
write()من البرنامج لحد الديسك - تفهم الـ Page Cache والـ fsync والـ Journaling
1. ليه الذاكرة مش كفاية؟
الـ RAM سريعة جداً، بس Volatile: أول ما الكهربا تقطع أو الجهاز يعمل Restart، كل اللي فيها بيضيع. فالداتا اللي لازم تفضل (الكود، والصور، والداتابيز، وإعدادات البرامج) لازم تتحط على جهاز Persistent: SSD أو HDD.
| RAM | NVMe SSD | HDD | |
|---|---|---|---|
| بعد انقطاع الكهربا | بتضيع | موجودة | موجودة |
| قراية عشوائية تقريباً | ~100 نانو ثانية | ~20–100 مايكرو ثانية | ~5–10 مللي ثانية |
| الوحدة | Byte | Page (غالباً 4 KB) | Sector (512 B أو 4 KB) |
يعني الديسك أبطأ من الـ RAM بآلاف المرات، وبيتعامل بـ بلوكات مش Bytes. والمطلوب من نظام التشغيل إنه يخبّي كل ده.
2. الملف: الفكرة اللي بتخبّي الديسك
خد بالك من فرق مهم عن الـ CPU والذاكرة: نظام التشغيل مش بيدّي كل برنامج ديسك افتراضي لوحده. بالعكس، الملفات معمولة عشان تتشارك: محرر الكود بيكتب app.php، و PHP بيقراه، و Git بيعمله Commit، و rsync بيرفعه على السيرفر. نفس الملف، وبرامج كتير.
3. رحلة write() لحد الديسك
لما Laravel يكتب سطر في storage/logs/laravel.log، ده اللي بيحصل تحت:
دوس ▶ شغّل، أو امشي خطوة خطوة بالأسهم.
ليه نظام التشغيل بيأخّر الكتابة كده؟
- يجمّع: 1000 كتابة صغيرة على نفس الملف بتبقى كتابة واحدة كبيرة على الديسك.
- يرتّب: يرتب الكتابات عشان الديسك يكتبها بأقل حركة.
- يلغي: لو ملف مؤقت اتكتب واتمسح في ثانية، ممكن عمره ما يوصل الديسك أصلاً.
والتمن إن write() لوحدها مش بتضمن إن الداتا مش هتضيع. علشان كده الداتابيز بتعمل fsync مع كل COMMIT، وده موضوع درس الـ Durability في موضوع الـ Transactions.
الـ write() بتكتب في الـ RAM وترجع. الديسك بيستلم بعدين. واللي محتاج ضمان بيطلب fsync ويدفع تمن الاستنا.
4. لو الكهربا قطعت وإنت في النص؟
إضافة سطر لملف ممكن تعني 3 تعديلات على الديسك: البلوك اللي فيه الداتا، وبيانات الملف (الحجم الجديد، وفين البلوكات بتاعته)، وخريطة البلوكات الفاضية. لو الكهربا قطعت بعد تعديل واحد بس، نظام الملفات نفسه ممكن يبقى متناقض: ملف حجمه بيقول 2 KB والبلوك مش متسجل له، أو بلوك متسجل إنه مستخدم ومحدش بيستخدمه.
الحلول الأساسية:
| الحل | الفكرة | مين بيستخدمه |
|---|---|---|
| Journaling | قبل التعديل، اكتب في Journal (سجل) “أنا هعمل كذا وكذا”، وبعد كده اعمله. لو وقعت في النص، اقرا الـ Journal وكمّل أو الغي | ext4، و XFS، و NTFS |
| Copy-on-Write | متعدّلش بلوك قديم أبداً: اكتب نسخة جديدة في مكان تاني، وفي الآخر حدّث مؤشر واحد للنسخة الجديدة | ZFS، و Btrfs، و APFS |
لو قريت موضوع الـ Transactions: الـ Journaling هو نفس فكرة الـ Write-Ahead Log في الداتابيز بالظبط. اكتب نيتك في سجل متسلسل الأول، وبعدين نفّذ.
5. أسئلة
فكّر في إجابتك الأول، وبعدين افتح السؤال.
01ليه البرامج محتاجة ديسك ومش الـ RAM بس؟
لأن الـ RAM Volatile: بتتمسح مع انقطاع الكهربا أو الـ Restart. أي داتا لازم تفضل لازم تتكتب على جهاز Persistent زي SSD أو HDD.
02ليه نظام التشغيل مش بيعمل ديسك افتراضي لكل برنامج زي ما بيعمل في الذاكرة؟
لأن الملفات معمولة عشان تتشارك بين البرامج: محرر يكتب، وكومبايلر يقرا، وأداة Backup تنسخ. العزل الكامل هنا ضد الهدف، فبدل كده فيه صلاحيات على الملفات.
03write() رجعت بنجاح. الداتا كده على الديسك؟
مش شرط. write() غالباً بتحط الداتا في الـ Page Cache في الـ RAM وترجع، والـ Kernel بيكتبها على الديسك بعدين. عشان تضمن إنها وصلت لازم fsync().
04يعني إيه Journaling في نظام الملفات؟
قبل ما نظام الملفات يعمل تعديل فيه كذا خطوة على الديسك، بيكتب وصف التعديل في سجل (Journal) الأول. لو حصل Crash في النص، بيقرا الـ Journal بعد الـ Restart ويكمّل التعديل أو يلغيه، فنظام الملفات مايفضلش متناقض. ونفس الفكرة هي الـ WAL في الداتابيز.