في إحدى البنى التحتية البرمجية لدى Facebook، كانت هناك مشكلة تبدو في البداية عادية: بعد انتهاء كل اختبار، كان ينبغي التخلص من الملفات التي خلّفها. لكن مع تضخم عدد هذه الملفات إلى ملايين، أصبح حذفها يستغرق دقيقتين أو ثلاثًا لكل اختبار، ويستهلك قدرًا كبيرًا من المعالج والتخزين.

كان من الممكن البحث عن حل في أدوات الاختبار نفسها، أو في أجهزة أسرع، أو في مزيد من القدرة الحاسوبية. لكن الحل جاء من مكان آخر تمامًا: نظام الملفات.

استخدم المهندسون لقطات Btrfs بدلًا من حذف ملايين الملفات واحدًا تلو الآخر. وبذلك انخفض زمن التخلص من بيئة الاختبار إلى ما يقارب الصفر، وتراجع عدد أجهزة البناء المطلوبة بنحو الثلث. خاصية تبدو للوهلة الأولى مجرد تفصيل تقني في نظام ملفات تحولت، على نطاق كبير، إلى وقت أقل وأجهزة أقل وتكلفة تشغيلية أقل.

هذه الحكاية الصغيرة تقول شيئًا مهمًا عن أنظمة الملفات. فنحن نراها عادةً كشيء مختبئ خلف مدير الملفات: نفتح مجلدًا، نحفظ صورة، نحذف مستندًا، ولا نفكر كثيرًا فيما يحدث خلف الشاشة. لكن وراء هذه البساطة طبقة كاملة من الهندسة تحدد كيف تُرتب البيانات، وكيف يُعثر عليها، وكيف تتغير، وكيف يمكن للنظام أن يتعامل معها عندما ينقطع التيار أو يحدث عطل.

ولهذا فإن تاريخ أنظمة الملفات ليس مجرد تاريخ لامتدادات مثل ext4 وXFS وBtrfs وZFS. إنه تاريخ لمحاولات متعاقبة لجعل الحاسوب يتعامل مع الذاكرة الرقمية بصورة أكثر كفاءة وأمانًا، كلما كبرت الأقراص، وتضخمت البيانات، وتغيرت طبيعة التخزين، وتغيرت احتياجات البشر من أجهزتهم.

لكن قبل أن نبدأ هذه الرحلة، من المفيد أن نتوقف لحظة عند سؤال بسيط: ما هو نظام الملفات أصلًا؟

نظام الملفات، في جوهره، هو المنهج الذي ينظّم به نظامُ التشغيل شؤونَ البيانات على وسيط التخزين؛ فبه يعرف أين يقع كل ملف، وبأيّ اسمٍ يُدعى، ومن يملك إليه سبيلاً، وكيف يُنشأ ويُعدَّل ويُمحى.

فحين تنشئ مجلدًا، أو تحفظ صورة، أو تفتح مستندًا، لا يُلقي النظام ببياناتك في فراغ القرص على نحو عشوائي؛ بل تعمل خلف الكواليس بنيةٌ محكمة تُسجِّل أسماء الملفات والمجلدات، وتصل كلَّ اسمٍ بموضع بياناته على القرص، وتحفظ إلى جوار ذلك سيرةَ كل ملف: حجمه، ووقت إنشائه، وآخر تعديلٍ طرأ عليه، ومن يحلّ له الوصول إليه.

وليس شأنُ نظام الملفات مقصورًا على الملفات وحدها؛ ففي نظامٍ مثل Linux يُناط به أيضًا ترتيبُ المجلدات، وملفات الأجهزة، والروابط، وبيانات الصلاحيات، وسائر ما تصطنع منه شجرةُ الملفات الممتدة أمامنا.

وعليه، حين نقول إن قسمًا من القرص مُهيّأٌ بنظام ext4 أو XFS أو Btrfs، فلسنا نتحدث عن اختلافٍ في تسمية الملفات فحسب، بل عن تصميمٍ هندسي متكامل يحدد كيف تُخزَّن البيانات، وكيف تُدار المعلومات التي تصفها، وكيف يتعامل النظام مع التغييرات والأعطال، وكيف يدبّر المساحة المتاحة.

وهنا يلزمنا تمييزٌ جوهري: نظام الملفات ليس هو القرص.

فالقرص وسيطُ التخزين الذي يحتفظ بالبيانات؛ أما نظام الملفات فمنهجُ تنظيمها فوق هذا الوسيط. ومن هنا أمكن تهيئة القرص نفسه بأنظمة ملفات شتى، بل تقسيمُه إلى عدة أقسام، يحمل كلٌّ منها نظامَ ملفاتٍ يخالف جاره.

فإذا نظرنا إلى القرص في ذاته، لم نجد إلا سلسلةً من الخانات المرقّمة، لا يُميَّز فيها ملفٌّ من فراغ؛ ونظام الملفات هو الذي يرسم فوقها الخريطة، ويضع لها القانون، حتى يستحيل الفراغُ مكتبةً منظمة.

لماذا لا يستخدم الجهاز نظام ملفات واحدًا لكل شيء؟

قد يبدو من الطبيعي أن يكون للقرص نظام ملفات واحد، لكن الحاسوب لا يستخدم كل أجزاء التخزين للغرض نفسه. هناك جزء يحتاج إلى تخزين نظام التشغيل وملفاته وصلاحياته، وجزء صغير قد يكون مخصصًا للإقلاع، ومساحة أخرى قد تستخدم لأغراض مختلفة تمامًا مثل swap. لذلك لا يوجد سبب تقني يجعل جميع هذه الأجزاء تستخدم الطريقة نفسها في تنظيم البيانات.

خذ قسم الإقلاع مثالًا. في أجهزة الحاسوب الحديثة التي تستخدم UEFI، يوجد قسم خاص يسمى EFI System Partition (ESP). هذا القسم لا يحتوي على نظام لينكس نفسه، بل على ملفات الإقلاع التي تحتاج إليها برمجيات UEFI قبل أن يبدأ نظام التشغيل. ولهذا يستخدم هذا القسم عادةً نظام FAT32، لأنه جزء من مواصفة UEFI التي تستطيع البرامج الثابتة في الجهاز التعامل معها مباشرة.

وهنا تظهر أهمية الاختيار: لو كان قسم الإقلاع مهيأً بـext4، فلن تكون المشكلة أن ext4 نظام ملفات سيئ، بل أن UEFI لا يفترض أن يعتمد على معرفة كيفية قراءة ext4. فالبرنامج الثابت يحتاج إلى نظام ملفات قياسي وبسيط يستطيع الوصول إليه قبل أن تبدأ نواة لينكس أصلًا.

أما القسم الذي يحتوي على نظام لينكس نفسه، فالوضع مختلف. هنا تكون النواة قد بدأت العمل، ويمكنها استخدام نظام ملفات مصمم خصيصًا لاحتياجاتها، مثل ext4 أو XFS أو Btrfs. ولذلك قد يكون جهاز واحد فيه FAT32 لقسم الإقلاع، وBtrfs أو ext4 للنظام، وأجزاء أخرى لها استخدامات مختلفة.

والـswap مثال جيد على أن ليس كل مساحة تخزين تحتاج أصلًا إلى نظام ملفات تقليدي. فهي مساحة يستخدمها نظام التشغيل كامتداد للذاكرة، ولذلك لها طريقة خاصة في إدارة البيانات ولا تُعامل كمجلد عادي يحتوي على ملفات.

إذن، استخدام أكثر من نظام ملفات ليس علامة على الفوضى أو التعقيد، بل نتيجة طبيعية لاختلاف الوظائف. كل جزء من التخزين يستخدم الطريقة التي تناسب المهمة التي يؤديها.

وهنا يأتي السؤال الأهم: إذا كانت هذه الأجزاء تستخدم أنظمة مختلفة، فكيف يستطيع لينكس أن يعرضها للمستخدم داخل شجرة واحدة، وأن يجعل البرامج تتعامل معها بالطريقة نفسها تقريبًا؟

كيف يجمع لينكس أنظمة الملفات المختلفة في شجرة واحدة؟

إذا كان /boot على FAT32، ونظام لينكس نفسه على ext4 أو Btrfs، فقد يبدو أن على البرامج أن تعرف في كل مرة أي نظام ملفات تتعامل معه. لكن هذا ليس ما يحدث.

هنا تأتي طبقة نظام الملفات الافتراضية (Virtual File System – VFS).

الفكرة الأساسية في VFS هي الفصل بين ما يريده البرنامج وكيفية تنفيذ الطلب داخل نظام الملفات. عندما يطلب برنامج فتح ملف أو قراءة مجلد أو إنشاء ملف جديد، فإنه يستخدم واجهة موحدة توفرها النواة. لا يحتاج البرنامج إلى معرفة ما إذا كان الملف موجودًا على ext4 أو Btrfs أو XFS.

وتتولى VFS توجيه الطلب إلى نظام الملفات المسؤول عن ذلك الجزء من شجرة الملفات. فيستطيع ext4 تنفيذ العملية بطريقته، ويستطيع Btrfs تنفيذها بطريقة أخرى، بينما يظل البرنامج الذي طلب العملية يتعامل مع الواجهة نفسها.

وهذه ليست مجرد وسيلة لجعل استخدام لينكس أسهل. إنها طريقة لتجنب ربط بقية النظام بتفاصيل كل نظام ملفات. فلو كان على كل برنامج أن يعرف كيف يعمل ext4 وBtrfs وXFS وFAT، لأصبح إضافة نظام ملفات جديد مشكلة تمتد إلى البرامج التي تتعامل مع الملفات. أما مع VFS، فيكفي أن يعرف البرنامج الواجهة، بينما تبقى تفاصيل التخزين في الطبقة المسؤولة عنها.

ولهذا يستطيع لينكس أن يجمع تقنيات مختلفة جدًا تحت شجرة واحدة. قد ينتقل المستخدم من مجلد على Btrfs إلى ملف موجود في نظام ملفات آخر، من دون أن تتغير الطريقة التي يتعامل بها مع الملفات.

وهنا تكمن الحكمة الأوسع: ليس المطلوب أن تكون التقنيات الموجودة في الأسفل متشابهة، بل أن تتفق على طريقة مشتركة للتعامل معها في الأعلى.

وهذه الفكرة، أكثر من مجرد القدرة على دعم نظام ملفات بعد آخر، هي التي جعلت بنية لينكس مرنة بما يكفي لتستوعب أجيالًا مختلفة من التخزين وأنظمة الملفات دون أن تضطر البرامج إلى إعادة تعلم معنى ملف كلما ظهرت تقنية جديدة.

من MINIX إلى ext2

في ثمانينيات القرن الماضي، أنشأ أندرو إس. تانينباوم نظام MINIX، وهو نظام شبيه بيونكس طُوّر في جامعة فرييه في أمستردام ليكون أداة تعليمية مرتبطة بكتابه Operating Systems: Design and Implementation. كان MINIX صغيرًا ومناسبًا للغرض الذي صُمم من أجله، لكنه لم يكن مجهزًا لاستيعاب الطموح المتزايد لمشروع لينكس الناشئ.

كان نظام ملفات MINIX يعاني من حدود واضحة: عناوين الكتل كانت مخزنة في أعداد صحيحة من 16 بت، وهو ما وضع حدًا لحجم نظام الملفات عند نحو 64 ميغابايت، كما كانت أسماء الملفات محدودة بـ14 حرفًا. في عالم الحواسيب آنذاك لم يكن ذلك أمرًا غريبًا، لكنه أصبح ضيقًا جدًا أمام نواة لينكس التي بدأت تتجاوز إطار المشروع التعليمي.

وهناك جانب آخر لا يقل أهمية عن الجانب التقني. لم يكن MINIX، وفق مفهوم البرمجيات الحرة الحديث، حرًا بالكامل. كان استخدامه مرتبطًا بترخيص بلغت تكلفته 69 دولارًا ضمن سعر الكتاب الذي كان يرافقه. لم يكن المبلغ وحده هو القضية؛ فقد كان نموذج التوزيع نفسه أكثر تقييدًا مما كان يريده بعض المطورين.

وهكذا التقت مشكلة تقنية بمشكلة اقتصادية. واحتاج لينكس إلى نظام ملفات أفضل، فوجد مشروعًا صغيرًا في طريقه إلى أن يصبح شيئًا أكبر بكثير من حجمه الأول.

في عام 1992 ظهر ext، أو نظام الملفات الممتد Extended File System، الذي طوّره ريمي كارد Rémy Card في إطار عمل أكاديمي في جامعة باريس LIP6. كان ext أول نظام ملفات صُمم خصيصًا للينكس، واستطاع رفع السقف بصورة كبيرة: حجم يصل إلى نحو 2 غيغابايت وأسماء ملفات تصل إلى 255 حرفًا.

لم يكن ext نهاية الطريق. كان مجرد خطوة أولى. وبعد عام واحد فقط، في 1993، ظهر ext2 بمشاركة ريمي كارد وثيودور تسو Theodore Ts’o وستيفن تودي Stephen Tweedie. استفاد ext2 من أفكار نظام Berkeley Fast File System، وجاء ليقدم أداءً واستقرارًا أفضل وأحجامًا أكبر بكثير من سلفه.

لكن ext2 كان يملك نقطة ضعف ستصبح مهمة جدًا مع انتشار لينكس في الخوادم: لم يكن يحتوي على دفتر يومية Journaling.

يمكن تصور دفتر اليومية كدفتر صغير يكتب فيه عامل المستودع ما ينوي فعله قبل أن يبدأ العمل. فإذا انطفأت الكهرباء فجأة، يستطيع عند عودته أن يفتح الدفتر ويعرف أين توقف، بدلًا من أن يفحص المستودع كله صندوقًا صندوقًا.

هذا تقريبًا ما يفعله الـJournaling يسجل النظام تغييرات معينة بطريقة تساعده على العودة إلى حالة متسقة بعد انقطاع الكهرباء أو انهيار النظام.

في ext2، كان الانقطاع المفاجئ قد يترك نظام الملفات في حالة تحتاج إلى فحص شامل باستخدام fsck. ومع كبر الأقراص وازدياد حجم البيانات، أصبح انتظار فحص طويل بعد كل انهيار أمرًا مرهقًا وغير عملي، خصوصًا في الخوادم.

كان واضحًا أن الجيل التالي يجب أن يتعلم كيف يتذكر ما كان يفعله قبل أن تنطفئ الأنوار.

ext3 الذاكرة تصبح جزءًا من التصميم

أستكمل ستيفن تودي عمله السابق في ex2 للعمل على ext3 في باريس أواخر التسعينيات، ووصل النظام إلى نواة لينكس في عام 2001. الإضافة الكبرى كانت دفتر اليومية.

الميزة لم تكن مجرد تحسين تقني؛ كان لها أثر اقتصادي واضح. يستطيع المستخدم الانتقال من ext2 إلى ext3 دون إعادة تهيئة القرص أو نسخ كل البيانات إلى مكان آخر. وكان الأمر tune2fs -j كافيًا لإضافة دفتر اليومية إلى نظام ملفات موجود.

هذه نقطة تبدو صغيرة اليوم، لكنها كانت مهمة جدًا في المؤسسات. كل عملية ترقية تعني وقتًا وتكلفة ومخاطرة. وكلما استطاعت تقنية جديدة أن تقول للمؤسسة: يمكنك الانتقال إليّ من دون هدم ما لديك، زادت فرصتها في النجاح.

في بداية الألفية لم يكن ext3 وحده في الساحة. كانت هناك عدة أنظمة ملفات تتنافس على مستقبل لينكس، من بينها ReiserFS وJFS وXFS. كان لكل منها خلفية مختلفة، ومؤسسة أو مجتمع مختلف يقف وراءه، وفلسفة مختلفة حول ما ينبغي أن يكون عليه نظام الملفات.

لكن ext3 امتلك شيئًا شديد القوة: تسجيل التغييرات قبل تنفيذها. لم يحاول أن يعيد اختراع كل شيء. أخذ ext2 الذي يعرفه الناس، وأضاف إليه ما كان ينقصه، ثم سمح للمستخدمين بالانتقال دون عناء يُذكر. وهذا أحد الأسباب التي جعلته يتقدم على منافسين أكثر طموحًا.

ReiserFS العبقرية والمأساة

في عام 2001 دخل ReiserFS إلى نواة لينكس الرسمية، وكان في الحقيقة أول نظام ملفات مزود بدفتر يومية يصل إليها قبل ext3.

طوّره هانز رايزر Hans Reiser وشركة Namesys، وجاء بأفكار متقدمة جدًا بالنسبة إلى ذلك الزمن. استخدم شجرة بي بلس B+ Trees لتنظيم البيانات، وامتلك تقنية تسمى Tail Packing تستطيع تجميع الأجزاء الصغيرة من الملفات بكفاءة، ما جعله مناسبًا خصوصًا للأدلة التي تحتوي على أعداد ضخمة من الملفات الصغيرة.

كان سريعًا وطموحًا، وأصبح لفترة نظام الملفات الافتراضي في SUSE. لكن قصة ReiserFS أخذت منعطفًا لا علاقة له بالبرمجة.

ففي عام 2006 أُلقي القبض على هانز رايزر واتُّهم بقتل زوجته نينا رايزر، ثم أُدين لاحقًا بالجريمة. تحولت القضية إلى واحدة من أغرب القصص في تاريخ البرمجيات الحرة: نظام ملفات متقدم يحمل اسم مطوره، بينما يتحول مطوره نفسه إلى شخصية مرتبطة بجريمة قتل حقيقية.

من الناحية التقنية، لم تكن الجريمة دليلًا على أن ReiserFS نظام سيئ. الشيفرة لا ترتكب الجرائم، والـ ـB+ Tree لا تعرف من كتبها.

لكن البرمجيات الحرة ليست معادلات رياضية معلقة في الفراغ. إنها نتاج بشر ومجتمعات وثقة وسمعة ومؤسسات. وبعد قضية رايزر تراجع الحماس لمستقبل Reiser4، كما اتجهت المؤسسات إلى خيارات أكثر رسوخًا وأقل مخاطرة. ومع مرور الوقت فقد ReiserFS مكانته، إلى أن أزيل من النواة الرئيسية ﻻحقاً.

وهنا تظهر مفارقة تستحق التوقف: حتى مجتمع يبدو شديد العقلانية والتقنية يتأثر بالعوامل الإنسانية والاجتماعية. لا يمكن فصل البرمجيات تمامًا عن البشر الذين يصنعونها.

ولذلك لم تكن مأساة ReiserFS مجرد قصة عن مطور ارتكب جريمة؛ كانت أيضًا مثالًا على أن استمرارية التقنية تعتمد على الثقة بالمشروع والمجتمع والمؤسسات، لا على جودة الخوارزمية وحدها.

JFS و XFS حين دخلت الشركات الكبرى

لم تكن كل القصص مأساوية. بعض أنظمة الملفات وصلت إلى لينكس من عالم الشركات الكبرى، حاملة معها خبرة تراكمت في أنظمة تجارية ضخمة.

من بينها JFS، وهو النظام الذي صممته IBM في تسعينيات القرن الماضي 1990، لبيئات الخوادم التجارية، قبل أن تقرر نقله إلى لينكس وتفتح شفرته المصدرية بين عامي 1999 و2000. وقد كانت IBM في تلك الفترة الفاصلة تضخ استثمارات ضخمة وتعيد النظر في علاقتها بعالم البرمجيات الحرة، بعد أن أدركت أن لينكس أصبح منصة يعتمد عليها قطاع الأعمال.

متجاوزةً وصف لينكس القديم بأنه ‘مجرد مشروع هواة’ (كما وصفه مبتكره في 1991)، وهو ما تجلى بوضوح عندما أعلنت IBM في يناير 2001 عن استثمار تاريخي بقيمة مليار دولار في لينكس، مما أثبت اعترافها الرسمي به كركيزة مؤسسية عالمية

وهنا يظهر البعد الاقتصادي بوضوح.

عندما تتبرع شركة ضخمة بتقنية متقدمة لمشروع مفتوح المصدر، لا يعني ذلك بالضرورة أنها تحولت فجأة إلى جمعية خيرية. أحيانًا يكون فتح الكود استثمارًا استراتيجيًا. إذا كان نظام التشغيل نفسه يتحول إلى سلعة متاحة للجميع، فقد يصبح من الأفضل للشركة أن تبيع الخوادم والمعالجات والتخزين والخدمات القائمة عليه، بدلًا من إنفاق طاقتها في الدفاع عن نظام تشغيل مغلق.

بعبارة أخرى، يمكن أن يكون جعل البرمجيات أرخص وسيلة لبيع العتاد الأغلى.

وهذا ينطبق بصورة واضحة على قصة XFS.

كانت شركة Silicon Graphics، أو SGI، تعمل في عالم مختلف عن عالم الحاسوب المكتبي. كانت أجهزة الشركة تستخدم في الرسوميات ثلاثية الأبعاد، وصناعة الأفلام، والحوسبة العلمية، ومجالات تحتاج إلى التعامل مع ملفات ضخمة وتدفق هائل من البيانات.

كان نظام الملفات الممتد EFS القديم لم يعد مناسبًا لهذا العالم. لذلك بدأت SGI في 1990 تطوير XFS، الذي ظهر على نظامهم للتشغيل IRIX عام 1994.

لم يكن XFS نسخة محسنة من ext2. كان تصميمًا جديدًا بُني منذ البداية ليعمل على أجهزة ضخمة وبالتوازي.

ولفهم الفكرة دون الغرق في التفاصيل، تخيل مستودعًا هائلًا لا يوجد فيه باب واحد لجميع العمال. قُسّم المستودع إلى مناطق مستقلة، وكل منطقة تستطيع التعامل مع عملياتها في الوقت نفسه. هذه هي الفكرة العامة وراء مجموعات التخصيص Allocation Groups في XFS: تقسيم نظام الملفات إلى مناطق يمكن أن تعمل بدرجة عالية من التوازي.

أما B+ Trees فتعمل كفهرس ضخم بدل البحث في الملفات واحدًا واحدًا. فإذا كان لديك ملايين العناصر، لا تريد من النظام أن يفتح كل درج حتى يجد ما تبحث عنه.

هذه الأفكار جعلت XFS مناسبًا للبيانات الكبيرة والأحمال التي تحتاج إلى معدل مرتفع ومستمر من عمليات الإدخال والإخراج.

وفي عام 1999 فتحت SGI كود XFS تحت رخصة جنو العمومية GPL، ثم بدأ نقله إلى لينكس. ومع مرور الوقت أصبح XFS أحد أعمدة أنظمة لينكس المؤسسية، وفي RHEL 7 الصادر سنة 2014 أصبح نظام الملفات الافتراضي للتثبيتات الجديدة.

كان هناك بُعد اقتصادي واضح مرة أخرى: فالشركات التي كانت تبيع أنظمة متخصصة وباهظة الثمن، أصبحت ترى في لينكس قاعدة مشتركة لصناعة أكبر. ولم يكن دعم لينكس بتقنيات احترافية مثل JFS وXFS مجرد كرم؛ بل كان جزءًا من معركة أوسع لتحويل نظام التشغيل إلى بنية تحتية مفتوحة ومشاعة للجميع، بينما تنتقل المنافسة الحقيقية إلى ساحة العتاد والخدمات والدعم

وهكذا دخلت الشركات الكبرى في عالم المصادر المفتوحة لا لأنها تخلت عن مصالحها، بل لأنها اكتشفت أن مصالحها نفسها قد تستفيد من ذلك.

تحدي المقاييس الضخمة

مع تطور XFS ظهرت فلسفة مختلفة عن فلسفة ext. لم يعد السؤال: كيف نحافظ على نظام ملفات بسيط وسريع؟ بل أصبح: كيف ندير كميات من البيانات كان من الصعب تخيلها عندما ظهر لينكس؟

حين تغيرت الأقراص، تغيرت طريقة التفكير

لكن أحجام الملفات ليست وحدها التي تغيرت. القرص نفسه تغير. في بدايات لينكس كان التخزين يعني، في الغالب، أقراصًا ميكانيكية ذات سعة محدودة، تتحرك فيها رؤوس القراءة والكتابة فوق سطح مغناطيسي. كان الوصول إلى البيانات مرتبطًا بحركة ميكانيكية فعلية، وكان ترتيب البيانات على القرص والتجزئة ومكان الكتل عوامل لها ثمن واضح في الأداء.

ثم كبرت الأقراص من عشرات الميغابايتات إلى غيغابايتات ثم تيرابايتات، وأصبحت الملفات أكبر، وأصبح من المعتاد أن يحتوي الجهاز الواحد على آلاف أو ملايين الملفات. لم يعد من الممكن تصميم نظام الملفات على افتراض أن التخزين مساحة صغيرة وثابتة لا تتغير كثيرًا.

ثم جاءت أقراص SSD، وغيرت جزءًا آخر من المعادلة.

لم تعد هناك رؤوس ميكانيكية تنتظر الوصول إلى موضع معين على سطح القرص. أصبحت الذاكرة الفلاشية تعمل بطريقة مختلفة، ولها خصائصها الخاصة في الكتابة وإعادة الكتابة وتوزيع البيانات. ولذلك بدأت أنظمة الملفات الحديثة تهتم أكثر بأمور مثل تجميع الكتابات، وتقليل الكتابة غير الضرورية، والضغط، وطريقة تخصيص المساحة.

وهنا يمكن فهم بعض الخيارات التي تبدو اليوم غريبة إذا نظرنا إليها بعيدًا عن تاريخ التخزين.

فالضغط في Btrfs، مثلًا، لا يعني فقط توفير مساحة. عندما تنجح عملية الضغط، قد يحتاج النظام إلى كتابة عدد أقل من البايتات إلى وحدة التخزين. وفي عالم SSD، حيث للكتابة تكلفة وأثر على عمر خلايا الذاكرة، يمكن أن تصبح خاصية مثل الضغط جزءًا من تحسين الأداء واستهلاك التخزين معًا. Fedora نفسها أشارت عند اعتماد Btrfs إلى مزايا مثل الضغط وتحسينات التعامل مع SSD.

وهكذا لم يعد نظام الملفات يتعامل مع القرص باعتباره مجرد أرض فارغة يضع فوقها الملفات. صار عليه أن يعرف شيئًا عن طبيعة الأرض نفسها.

وهذا أحد أسباب اختلاف الأجيال. فـ ext2 وext3 وext4 نشأت في عالم تخزين مختلف عن العالم الذي ظهرت فيه Btrfs وZFS. لم يكن المطلوب في كل مرة مجرد زيادة حجم النظام، بل إعادة التفكير في العلاقة بين البيانات، ووسيط التخزين، والانقطاع، والنسخ، والتحقق من السلامة.

ومع انتقال العالم من الأقراص الميكانيكية إلى SSD ثم إلى أشكال أحدث من التخزين، أصبحت بعض الافتراضات القديمة أقل أهمية، بينما أصبحت قضايا أخرى أكثر إلحاحًا: كيف نقلل الكتابة؟ كيف نكتشف تلف البيانات الصامت؟ كيف نتعامل مع أحجام هائلة؟ وكيف نستفيد من التخزين السريع من دون أن نحول سرعة العتاد إلى فوضى في إدارة البيانات؟

لهذا فإن تاريخ أنظمة الملفات هو، في جانب منه، تاريخ تطور الأقراص نفسها. كلما تغيرت المادة التي تحفظ البيانات، اضطر البرنامج الذي ينظمها إلى أن يتعلم لغة جديدة.

ظل XFS يتطور، وأضيفت إليه بنية أحدث باسم XFS V5، تضمنت تحسينات في سلامة البيانات الوصفية، وتدقيقها باستخدام CRC، وتقنيات متقدمة مثل reverse mapping B+tree.

أي أن نظام الملفات بدأ يحتفظ بمعلومات أكثر عن نفسه، بحيث يستطيع التحقق من هياكله الداخلية وإجراء عمليات صيانة أكثر تطورًا.

ومن التحسينات المهمة أيضًا bigtime، الذي يمدد نطاق الطوابع الزمنية Timestamps ويؤجل مشكلة عام 2038 إلى قرون لاحقة.

📌 ما هي مشكلة عام 2038؟

تخزّن معظم أنظمة يونكس الوقت كعدد من الثواني منذ الأول من يناير 1970 (ما يُعرف بـ Unix Epoch). المشكلة أن هذا العدد يُحفظ في متغير من 32 بت، وأقصى قيمة يمكنه حملها ستُستنفَد في 19 يناير 2038 الساعة 03:14:07 بتوقيت غرينتش. عند تلك اللحظة، ينقلب العداد فجأة إلى رقم سالب، فيرتد التاريخ إلى عام 1901. تمامًا كما انقلبت عدادات السيارات القديمة من 999,999 إلى صفر. النتيجة: فوضى كاملة في كل نظام يعتمد على التواريخ، من قواعد البيانات إلى شهادات الأمان.

وهنا تظهر قضية أكبر من XFS نفسه: الزمن الرقمي.

عندما صمم المبرمجون الأوائل أنظمة الوقت في الحواسيب، لم يتوقع كثير منهم أن تبقى برامجهم وهياكلهم الأساسية قيد الاستخدام بعد نصف قرن تقريبًا. كانت سنة 2038 تبدو بعيدة إلى درجة لا تستحق القلق. لكن الحاسوب لا ينسى حساباته القديمة بسهولة.

اليوم يحاول المطورون تمديد عمر هذه التصاميم، وكأننا نحاول ترميم ساعة صنعت قبل عقود حتى تستمر في العمل بعد أن تجاوزت عقاربها العمر الذي تخيله صانعها.

ولـXFS ثمن آخر: لا يمكن تصغير نظام الملفات في مكانه، بل يمكن توسيعه فقط. كما أن أدوات الإصلاح القوية ليست ألعابًا؛ استخدام خيارات مثل xfs_repair -L قد يؤدي إلى التخلص من معاملات ما زالت في السجل، ولذلك لا ينبغي التعامل معه كزر إصلاح سريع.

شهدت أنظمة XFS سيناريوهات معقدة تشابكت فيها هشاشة العتاد مع فساد البيانات، ليزيد الخطأ البشري الطين بِلَّةً.
ففي إحدى الحوادث، كان استخدام الخيار -L (Log Force) في أداة إصلاح XFS (xfs_repair) على خادم يعمل بقواعد بيانات هو المسمار الأخير في نعش البيانات؛ بيانات كانت لا تزال قابلة للإنقاذ لو عُومل سجل النظام Journal بالحذر اللائق.

تذكر دائماً أن الآلة كيان أعمى عن النوايا؛ إذا أمرتها بـ محو سجل العمليات، فلن تتساءل عن السبب، بل ستنفذ ذلك حرفياً وفوراً، بغض النظر عن العواقب الوخيمة، محولةً خطأً بسيطاً إلى كارثة لا رجعة فيها

ext4 النضج

بينما كانت XFS تتجه إلى عالم البيانات الضخمة، كان ext يتطور بطريقة أكثر تحفظًا.

ظهر ext4 في نواة لينكس 2.6.28 عام 2008، وجاء ليحافظ على السمعة التي بناها ext3 مع رفع السقف في الأداء والحجم.

أحد أهم التغييرات كان Extents. بدل أن يتعامل النظام مع كل كتلة من الملف كأنها قطعة منفردة، يستطيع وصف مجموعة متصلة من الكتل باعتبارها وحدة واحدة.

تخيل بدلًا من كتابة «الملف موجود في الغرفة 1، ثم 2، ثم 3، ثم 4…» أن تكتب ببساطة: «الملف موجود في الغرف 1–4». عندها يقل حجم الفهرس، وتصبح إدارة الملفات الكبيرة أكثر كفاءة.

كما أضيفت دقة أعلى للطوابع الزمنية، وأحجام أكبر للملفات وأنظمة الملفات، وتحسينات في دفتر اليومية.

لكن ext4 حمل معه نقاشًا مهمًا حول التخصيص المؤجل Delayed Allocation.

تكمن عبقرية هذا المفهوم في بساطته: لا يقرر النظام فورًا أين سيضع كل البيانات التي يكتبها البرنامج. يؤجل القرار قليلًا، حتى تتجمع صورة أفضل عن البيانات المطلوب كتابتها. هذا يساعد على تقليل التجزئة وتحسين الأداء.

لكن تحسين الأداء يعني أحيانًا قبول قدر من التعقيد. ففي حال تعطل النظام أو انقطاع الطاقة قبل إتمام كتابة البيانات فعلياً على القرص، قد ينتهي الأمر بفقدان البيانات فعلياً، خلافاً لما يتوقعه المستخدم. وهنا اشتعل نقاش واسع في مجتمع لينكس عام 2009 حول العلاقة بين السرعة وضمانات حفظ البيانات، وعبّر لينوس تورفالدس عن اعتراض شديد على بعض قرارات التصميم.

المسألة لم تكن أن ext4 غير آمن، بل أن تصميم نظام الملفات يجب أن يوازن بين الأداء وضمانات التطبيق. فالبرنامج الذي يحتاج إلى ضمان أن البيانات وصلت فعلًا إلى التخزين يستطيع استخدام fsync()، بينما قد تكون بعض التطبيقات أكثر تساهلًا مع قدر محدود من المخاطرة.

وفي عالم الخوادم، لا توجد إجابة واحدة تصلح للجميع. فقد يكون فقدان ثوانٍ من العمل مقبولًا في جهاز مكتبي، بينما يكون غير مقبول إطلاقًا في نظام مالي.

وقد ظهرت أيضًا أخطاء حقيقية في البرمجيات المؤسسية. ففي RHEL 6 ظهر عام 2013 خلل مرتبط بالتزامن والكتابة إلى التخزين، وكان مسجلًا داخليًا برقم Bug 955807. مثل هذه الحوادث تذكرنا بأن نضج نظام الملفات لا يعني أنه معصوم من الأخطاء.

ومع ذلك، نجح ext4 نجاحًا هائلًا. تبنته توزيعات كثيرة، وانتقل إلى الأجهزة المضمنة Embedded Systems والهواتف. وفي 2010 أعلنت Google انتقال بنية التخزين لديها إلى ext4، كما اعتمد Android 2.3 ext4.

كان ext4 أقل إثارة من بعض منافسيه، لكنه كان يعرف شيئًا مهمًا جدًا: الاستقرار نفسه ميزة تقنية.

خريطة سريعة لعائلة ext

هذه السلسلة تكشف شيئًا مهمًا: لم يكن كل جيل ثورة منفصلة. أحيانًا يكون أفضل طريق إلى المستقبل هو أن تبني الطابق الجديد فوق المبنى القديم، بدل أن تهدمه وتبدأ من الأرض.

Btrfs وZFS جيل جديد

في عام 2007 بدأ كريس ماسون Chris Mason، الذي كان يعمل لدى Oracle، مشروع Btrfs. كان الهدف أكثر طموحًا من مجرد إضافة ميزة إلى ext. كان يهدف إلى بناء نظام ملفات حديث يستطيع التعامل مع التخزين كما لو كان نظامًا متكاملًا لإدارة البيانات.

استفاد Btrfs من أفكار ظهرت في أنظمة حديثة مثل ZFS، لكنه صُمم ليندمج مع لينكس تحت GPL.

الأساس هنا هو الكتابة عند النسخ (Copy-on-Write – CoW).

تخيل أنك تملك مخطوطة قديمة. عندما تريد تعديل فقرة، لا تمحو النص الأصلي مباشرة. تكتب النسخة الجديدة في مكان آخر، ثم تغيّر الفهرس ليشير إليها. إذا حدث انقطاع في الكهرباء أثناء العملية، تبقى النسخة القديمة موجودة.

هذه الفكرة تفتح الباب أمام إمكانات قوية: اللقطات الزمنية Snapshots، والاستنساخ، والضغط، والتحقق من سلامة البيانات، وإدارة عدة أقراص ضمن مجموعة واحدة.

كما أن Btrfs يستطيع الاحتفاظ ببيانات تحقق لكل كتلة، بحيث يستطيع اكتشاف فساد البيانات الصامت الناتج عن عطل في التخزين.

لكن الطموح له ثمن.

كان Btrfs في مراحله الأولى شديد الطموح، ولم تكن كل أجزاء النظام ناضجة بالدرجة نفسها. ظهرت مشكلات في الأداء والاستقرار، وكانت RAID 5/6 تاريخيًا من أكثر الأشياء التي استدعت الحذر. كما يمكن لطبيعة Copy-on-Write أن تزيد التجزئة في بعض أحمال العمل، خصوصًا على الأقراص الميكانيكية.

وهنا ظهرت واحدة من أهم التجارب المؤسسية في تاريخ Btrfs، حيث انقسمت الرؤى بشكل حاد، لكن القصة لم تتوقف عند هذا الحد.

راهنَت SUSE عليه مبكراً؛ فمنذ إصدار SUSE Linux Enterprise (SLE) 12 عام 2014، أصبح Btrfs نظام الملفات الافتراضي لقسم الجذر، واستثمرت الشركة موارد هندسية ضخمة لدمجه مع أدوات مثل Snapper لتمكين استعادة النظام بضغطة زر بعد التحديثات الفاشلة.

في المقابل، سلكَت Red Hat طريقاً أكثر تحفظاً في منتجاتها المؤسسية RHEL. فبعد سنوات من التقييم، قررت أن المخاطر الكامنة وتكلفة الصيانة المستمرة لا تبرران اعتماده كخيار افتراضي، فأعلنت إهماله تدريجياً في RHEL 7، قبل أن تزيله تماماً بدءاً من RHEL 8 لترسخ بديلاً أكثر نضجاً وموثوقية مثل XFS.

لكن المشهد شهد تحولات دراماتيكية أعادت تشكيل مصير هذا النظام:

أولاً، على مستوى المجتمع المفتوح المصدر، اعتمدت Fedora 33 (في عام 2020) نظام Btrfs كخيار افتراضي لنسخ سطح المكتب، مما يعكس ثقة المشروع في نضجه للاستخدام العام.

ثانياً، على مستوى الإنتاج الضخم، أثبتت Facebook (Meta) جدوى هذا النظام بتشغيله على ملايين الخوادم في بيئات الإنتاج الفعلية، حيث ساهم في تقليل التكاليف وتحسين الكفاءة على مستوى بيتابايت من البيانات، مما دحض عملياً مزاعم عدم استقراره في بيئات عمالقة الحوسبة السحابية Hyperscale.

وأخيراً، استجابةً لطلب المطورين، قامت توزيعات مثل AlmaLinux (بدءاً من الإصدار 10.1) و CentOS Stream (عبر قناة Hyperscale SIG) بإعادة دعم Btrfs بشكل كامل، مقدمةً بذلك ‘ملاذاً’ تقنياً لهذا النظام بعد أن تخلت عنه RHEL، مما يثبت أن ديناميكيات المصادر المفتوحة تسمح للمجتمع بتصحيح المسار أو تلبية احتياجات لم تغطِها الشركات الكبرى.

لا يعني ذلك أن أحد الطرفين كان على حق مطلق والآخر مخطئاً. بالنسبة إلى SUSE و Facebook، كان الاستثمار في Btrfs وسيلة للحصول على ميزات متقدمة (مثل الضغط الفوري والاستعادة السريعة) تبرر التعقيد الهندسي. وبالنسبة إلى Red Hat، كان السؤال الجوهري: هل نريد أن ننفق جهوداً هندسية هائلة للحفاظ على نظام معقد في بيئة مؤسسية تقليدية، بينما تتوفر بدائل أكثر تحفظاً وموثوقية؟

النظام نفسه، لكن تجربة مختلفة

ومن السهل هنا أن نقع في خطأ آخر: أن نتعامل مع اختيار نظام الملفات كما لو أنه قرار مستقل عن التوزيعة.

خذ Btrfs مثالًا واضحًا. يمكن لتوزيعتين أن تختارا نظام الملفات نفسه، لكنهما قد تبنيان فوقه تجربتين مختلفتين تمامًا.

في openSUSE، أصبح Btrfs جزءًا من فلسفة إدارة النظام نفسها. لا يقتصر الأمر على وضع الملفات على Btrfs، بل يرتبط به Snapper واللقطات الزمنية، وتستفيد عمليات مثل zypper وYaST من هذه البنية لإنشاء نقاط يمكن الرجوع إليها. ولهذا فإن المستخدم لا يشعر بأن Btrfs مجرد نظام تخزين خلفي؛ بل يصبح جزءًا من طريقة تحديث النظام واستعادته. ففي openSUSE، يُستخدم Btrfs افتراضياً لقسم الجذر، وتقوم أداة Snapper بإنشاء لقطات تلقائية قبل التغييرات وبعدها، مما يسمح باستعادة النظام إلى حالته السابقة بسهولة.

أما Fedora فقد اختارت Btrfs أيضًا، لكن الدافع وطريقة تقديمه مختلفان. منذ Fedora 33 أصبح Btrfs نظام الملفات الافتراضي لإصدارات سطح المكتب، وتستخدم التثبيتات الجديدة Subvolumes للجذر و/home داخل نظام ملفات واحد، بحيث تشترك هذه الأجزاء في المساحة نفسها بدل تقسيمها إلى أقسام ثابتة. كما استفادت Fedora من الضغط التلقائي للبيانات وخصائص Btrfs الحديثة، لكنها لم تجعل تجربة سطح المكتب مبنية حول Snapper بالطريقة نفسها التي فعلتها openSUSE.

إذن، عبارة «هذه التوزيعة تستخدم Btrfs» لا تخبرنا بالقصة كاملة.

فـ ـBtrfs في openSUSE ليس هو التجربة نفسها التي يمثلها Btrfs في Fedora، رغم أن نظام الملفات واحد. الاختلاف يأتي من الطبقة التي تبنيها التوزيعة حوله: بنية الـSubvolumes، وأدوات الإدارة، وسياسة اللقطات، وطريقة التحديث، وأدوات الاستعادة، وحتى الافتراضات التي تضعها أداة التثبيت.

وهنا تظهر فكرة أوسع في عالم لينكس: التوزيعة لا تختار المكونات فقط؛ إنها تختار كيف تتعاون هذه المكونات معًا.

ولهذا قد يكون من الأدق أحيانًا ألا نسأل: «هل تستخدم التوزيعة Btrfs؟»، بل أن نسأل: «ماذا تفعل التوزيعة بـBtrfs؟»

وهذا الفرق مهم جدًا للمستخدم. فقد يثبت شخصان النظام نفسه باستخدام Btrfs، لكن أحدهما يحصل على وسيلة عملية للرجوع عن تحديث فاشل، بينما يحصل الآخر أساسًا على مرونة أكبر في توزيع المساحة والضغط والـSubvolumes. النظام واحد، لكن الفائدة التي يراها المستخدم مختلفة.

ZFS جدار الترخيص

إذا كان Btrfs محاولة طموحة لبناء نظام ملفات حديث من داخل مجتمع لينكس، فإن ZFS كان ولا يزال أحد أكثر أنظمة الملفات ثورية في عالم يونكس UNIX.

طوّرته شركة Sun Microsystems في بداية الألفية، وظهر رسمياً في نظام Solaris 10 عام 2005. جمع ZFS بين نظام الملفات وإدارة وحدات التخزين في كيان واحد متماسك، واستخدم تقنية النسخ عند الكتابة Copy-on-Write، وقدم عمليات تدقيق Checksums للبيانات والبيانات الوصفية على حد سواء، بالإضافة إلى لقطات زمنية فورية، وتقنية RAID-Z، وإمكانات للإصلاح الذاتي عند وجود تكرار للبيانات.

تعود إحدى الروايات المرتبطة بولادته إلى حادثة فادحة لفساد في خريطة تخزين داخل شركة Sun. أظهر ذلك للفريق الهندسي مدى خطورة أن يثق نظام التخزين ثقة عمياء في الطبقات الموجودة تحته (العتاد). كانت الفكرة بسيطة وحاسمة: لا تفترض أن العتاد معصوم من الخطأ. ولذلك، صُمم ZFS ليكون واعياً تماماً بما يحدث للبيانات في كل لحظة.

لكن أقوى ما في ZFS لم يكن تحديه التقني للعتاد، بل تحديه القانوني لمجتمع البرمجيات الحرة.

فقد أُصدر ZFS تحت رخصة CDDL (رخصة التطوير والتوزيع المشتركة)، في حين أن نواة لينكس محمية بصرامة تحت رخصة GPLv2 (رخصة جنو العمومية). المعضلة هنا ليست في أن إحدى الرخصتين مغلقة، بل في أنهما غير متوافقتين قانونياً؛ فلا يمكن دمج كود مرخص بـ CDDL داخل نواة مرخصة بـ GPL دون انتهاك شروط إحداهما.

وبالتالي، تحول عدم التوافقية هذا، إلى حاجز قانوني يستحيل اختراقه يمنع دمج ZFS بشكل رسمي في النواة الرئيسية للينكس.

وهنا يظهر أحد أهم دروس تاريخ البرمجيات الحرة: قد تمتلك تصميماً تقنياً متفوقاً يغير قواعد اللعبة، لكنك تعجز عن دمجه في المكان الذي تريده بسبب شروط الترخيص المرفقة بالكود، والتي تفرض قيوداً لا يمكن التوفيق بينها.

يمكن النظر إلى هذا الصراع بطريقة أقل جفافاً قانونياً وأكثر إنسانية: كانت هناك تقنية رائعة محاصرة بقيود ترخيصية، بينما يسعى مجتمع لينكس للبناء على أرضية موحدة ومتوافقة مع فلسفته. لم يكن الجدل مجرد “أي نظام ملفات أفضل؟"، بل “من يملك الحق في دمج هذا الكود مع ذاك؟”.

ومن هذه الزاوية بالتحديد، يتضح لماذا وُلد Btrfs: لم يكن Btrfs مجرد منافس تقني لـ ZFS فحسب، بل كان محاولة طموحة وضرورية لبناء بديل يحمل الأفكار نفسها تقريباً (مثل النسخ عند الكتابة، واللقطات، والتدقيق)، ولكن ضمن البيئة القانونية والفلسفية المتوافقة تماماً مع رخصة لينكس (GPL)، مما يضمن بقاءه جزءاً أصيلاً من النواة وليس مجرد إضافة خارجية محفوفة بالمخاطر.

عندما تصبح الشركة جزءًا من التاريخ

في عام 2010 استحوذت Oracle على Sun. ثم تغير مستقبل OpenSolaris، وظهرت مخاوف بشأن مستقبل النسخة المفتوحة من ZFS.

كان رد المجتمع إنشاء illumos، ثم ظهر OpenZFS عام 2013 كمشروع يجمع التطوير المفتوح حول قاعدة مشتركة.

اليوم توجد منظومة OpenZFS النشطة إلى جانب تطبيق Oracle الخاص بـZFS على Solaris.

أما في لينكس، فظل ZFS يعمل خارج النواة الرئيسية عبر وحدة مستقلة، ووجد جمهورًا وفيًا بين المستخدمين الذين يحتاجون إلى خصائصه.

لكن ZFS، مثل أي نظام ملفات آخر، ليس عصا سحرية.

فقد سجلت حالات حقيقية لفساد شديد في بيانات وصفية لمجمعات ZFS بعد انقطاع طاقة، حتى مع وجود RAID-Z2 وذاكرة ECC، ولم يكن الحل في النهاية سوى النسخ الاحتياطي.

وهذا يعيدنا إلى قاعدة ربما تكون أهم من كل ميزات ZFS وBtrfs:

نظام الملفات ليس نسخة احتياطية.

يمكن لنظام ملفات متقدم أن يكتشف بعض أنواع الفساد ويصلح بعضها، لكنه لا يستطيع أن يحميك من الحذف الخطأ، أو البرمجيات الخبيثة، أو تلف شامل، أو خطأ بشري، أو كارثة تصيب النظام كله.

من لينكس إلى Windows و macOS

لم يبق تأثير أفكار أنظمة ملفات لينكس داخل لينكس. كانت العلاقة بين أنظمة التشغيل المنافسة وأنظمة الملفات علاقة أخذ وعطاء طويلة. ظهرت أدوات تسمح لـ ـWindows وmacOS بقراءة بعض أنظمة ملفات لينكس، كما ظهرت الحاجة إلى تبادل الأقراص والبيانات بين البيئات المختلفة.

لكن التحول الأكبر جاء من Microsoft.

لسنوات طويلة كان عالم Windows قائمًا حول NTFS وFAT، بينما كان لينكس يعيش في عالم مختلف. ثم بدأت Microsoft تغير موقفها تجاه لينكس، وكان WSL2 واحدًا من أوضح رموز هذا التحول.

في WSL2 توجد نواة لينكس حقيقية تعمل داخل بيئة Windows، وتستخدم بيئات التوزيعات أقراصًا افتراضية بنظام ext4. كما يستطيع المستخدم استخدام wsl --mount للوصول إلى أقراص أو أقسام فعلية من داخل بيئة لينكس.

يمكن النظر إلى ذلك بوصفه أكثر من مجرد ميزة توافق.

في التسعينيات كان السؤال: «كيف نجعل لينكس يعمل مع Windows؟»

بعد عقود أصبح السؤال من Microsoft نفسها: «كيف نجعل لينكس يعمل داخل Windows؟»

لم يحدث هذا لأن Microsoft وقعت فجأة في حب فلسفة المصادر المفتوحة. الاقتصاد هو الذي تغير.

المطورون يريدون Linux وGit والحاويات وأدوات الخوادم، والشركات تريد أن يبقى هؤلاء المطورون داخل منظومة Windows وAzure. لذلك أصبح احتضان لينكس أكثر فائدة من محاربته.

كانت هذه واحدة من أكثر الانتصارات هدوءًا في تاريخ لينكس: لم يحتج النظام إلى الاستيلاء على سطح مكتب Windows؛ يكفي أن يصبح مهمًا إلى درجة أن منافسه الأكبر يضعه داخل حدوده.

exFAT و NTFS

في الاتجاه الآخر، احتاج لينكس أيضًا إلى التعامل مع عالم Windows.

كان exFAT مثالًا واضحًا على البعد الاقتصادي للملكية الفكرية. لسنوات كانت Microsoft تملك حقوقًا وبراءات مرتبطة بتقنيات FAT وexFAT، ودفعت شركات مختلفة رسومًا مقابل استخدام بعض هذه التقنيات.

لكن في 2019 نشرت Microsoft مواصفات exFAT علنًا، ودعمت إدخاله إلى النواة. جاء ذلك في مرحلة أصبحت فيها Microsoft نفسها تعتمد اقتصاديًا على Linux في Azure والخدمات السحابية.

ومرة أخرى تغيرت المعادلة:

ما كان في مرحلة سابقة وسيلة لحماية الملكية أصبح في مرحلة لاحقة وسيلة لتوسيع السوق.

ثم جاء NTFS3 من Paragon Software، وأضيف إلى النواة الرئيسية في Linux 5.15، ليقدم دعمًا أصليًا للقراءة والكتابة على NTFS.

لم تعد الحدود بين أنظمة الملفات حدودًا صلبة بين «نحن» و«هم». أصبح المستخدم يعيش في عالم هجين: Windows على قسم، وLinux على قسم آخر، وWSL بينهما، وقرص exFAT ينتقل بين الأجهزة.

وهكذا بدأت أنظمة الملفات نفسها تتحول إلى لغة مشتركة بين الأنظمة.

APFS حين تعلّمت Apple من الآخرين

في 2016 كشفت Apple عن APFS، نظام ملفات Apple الجديد، الذي وصل إلى المستخدمين مع macOS High Sierra عام 2017.

كان الهدف مختلفًا عن أهداف XFS أو ZFS. لم تكن Apple تبني نظام تخزين لمركز بيانات مفتوح متعدد الشركات، بل نظامًا يخدم منظومة تتحكم الشركة في عتادها وبرمجياتها معًا.

ومع ذلك ظهرت أفكار مألوفة لمن تابع تطور أنظمة الملفات الحديثة: Copy-on-Write، وSnapshots، وClones، وSpace Sharing، وتكامل قوي مع التشفير.

لم تكن Apple تنسخ ZFS أو Btrfs، لكن مهندس APFS الرئيسي دومينيك جيامباولو Dominic Giampaolo أشار إلى معرفته بهذه الأنظمة الحديثة. وكان الفريق حريصًا على ألا يعتمد على تفاصيل تنفيذها بصورة قد تسبب مشكلات قانونية أو برائية.

وهنا تتكرر الفكرة نفسها: الأفكار لا تعيش دائمًا داخل حدود الرخصة التي ولدت فيها.

يمكن لشركة أن تنظر إلى فكرة ظهرت في مجتمع مفتوح، تتعلم منها، ثم تبني تنفيذًا مختلفًا يناسب عالمها الخاص.

وتزداد أهمية هذه القصة عندما نعرف أن Apple نفسها حاولت قبل ذلك تبني ZFS.

بدأت الشركة العمل على منفذ لـZFS نحو عام 2007، وعرضت نسخة للقراءة فقط في WWDC 2008. لكن المشروع توقف لاحقًا، وسط مجموعة من العوامل القانونية والتقنية والاستراتيجية، من بينها مشكلات الترخيص والمخاطر القانونية المرتبطة بـZFS.

وكانت النتيجة مفارقة تاريخية جميلة:

لم تدخل ZFS إلى macOS، لكن أفكار الجيل الذي مثلته لم تختفِ. بل ظهرت، بصورة مستقلة، في APFS. وهكذا قد تمنع الرخصة نقل الشيفرة، لكنها لا تستطيع منع المهندسين من التعلم.

أي نظام ملفات تختار اليوم؟

بعد كل هذا التاريخ، لا يحتاج المستخدم العادي إلى حفظ عشرات الأسماء والتفاصيل. يكفي أن يعرف السؤال الذي يحاول كل نظام ملفات الإجابة عنه.

1. جهاز سطح المكتب (Desktop)

بالنسبة لمعظم توزيعات لينكس التقليدية، يظل ext4 خياراً ممتازاً وآمناً. فهو ناضج، واسع الدعم، مستقر، وتحيط به خبرة هائلة من المستخدمين وأدوات الاستعادة.

لكن إذا كنت تستخدم توزيعة تجعل Btrfs جزءاً أساسياً من تصميمها (مثل openSUSE أو Fedora الحديثة)، فقد تكون مزايا اللقطات الزمنية (Snapshots) والأقسام الفرعية (Subvolumes) والضغط التلقائي سبباً منطقياً قوياً لاختياره.

القاعدة هنا: لا تحتاج إلى Btrfs لمجرد أنه أحدث، ولا تحتاج إلى ext4 لمجرد أنه أقدم. اختر ما يتناسب مع بيئة عملك، أو التزم بالخيار الافتراضي الذي تقدمه التوزيعة إذا لم تكن لديك متطلبات خاصة.

2. خادم ملفات أو قاعدة بيانات (Server & Database)

يُعد XFS خياراً قوياً ومفضلاً عندما يكون الحمل قائمًا على ملفات كبيرة أو عمليات إدخال وإخراج متوازية، ولذلك يحتل مكانة محورية في بيئات الخوادم والمؤسسات.

لكن لا توجد قاعدة مطلقة تقول إن XFS هو الأفضل لكل خادم. نوع التطبيق، وأدوات النسخ الاحتياطي، وحاجة النظام المستقبلية لتغيير حجم التخزين، كلها عوامل حاسمة.

⚠️ يمكن لنظام XFS التوسع (Expansion)، لكنه لا يدعم تقليص حجم نظام الملفات (Shrinking). لذلك، ينبغي التخطيط لمساحة التخزين بعناية منذ البداية.

3. اللقطات والمرونة (Snapshots & Flexibility)

إذا كانت القدرة على تجربة تغييرات جذرية على النظام ثم العودة إلى حالة سابقة بضغطة زر هي جزء أساسي من احتياجاتك، فإن Btrfs يصبح خياراً جذاباً جداً. فهو يوفر:

• لقطات زمنية فورية (Snapshots).
• أقساماً فرعية مستقلة (Subvolumes).
• تدقيقاً (Checksums) للبيانات والبيانات الوصفية.
• ضغطاً تلقائياً للبيانات.
• إدارة مدمجة لأقراص تخزين متعددة.

👀 مرونة Btrfs لا تعني أنه مناسب لكل سيناريو. تحديداً في تكوينات RAID 5/6 الأصلية (Native Parity)، لا يزال النظام يعاني من مشاكل معروفة مثل الثقب في الكتابة (Write Hole) وبطء عمليات الفحص والإصلاح (Scrub)، مما يجعله غير مُوصى به لبيئات الإنتاج أو البيانات الحرجة حسب التحذيرات الرسمية لمطوريه في نواة لينكس.

💡 قد يخلط بعض المستخدمين بين هذا التحذير وبين ما تقدمه أجهزة NAS من شركة Synology. لكن تجدر الإشارة إلى أن Synology تستخدم نسخة مُعدّلة ومُحسّنة بشدة من Btrfs (تتضمن إصلاحات وأدوات إدارة خاصة بها) تختلف جوهرياً عن النسخة القياسية المتاحة في نواة لينكس الرئيسية (Mainline). لذا، لا ينبغي تعميم تجربة Synology الناجحة على استخدام Btrfs في خوادم أو أجهزة لينكس التقليدية.

4. التخزين المنزلي و NAS

إذا كان جهاز NAS أو الخادم المنزلي يدعم Btrfs بشكل جيد، فقد يكون خياراً عملياً جداً، خصوصاً عندما تكون اللقطات المحلية والتحقق من سلامة البيانات أولوية.

أما ZFS فيبرز عندما ترغب في منظومة متكاملة وقوية لإدارة التخزين، وتمتلك العتاد المناسب (خاصة ذاكرة RAM كافية) والخبرة اللازمة لإدارته. لكن تذكر أن ZFS ليس مجرد نظام ملفات، بل هو منظومة تخزين كاملة لها متطلباتها الخاصة، وتتأثر في بيئة لينكس بقضايا الترخيص والتكامل مع النواة.

لا الـ Snapshot ولا الـ ZFS يعتبران “نسخة احتياطية” (Backup). إذا تلف الجهاز بالكامل أو تعرض للسرقة، فلن تنقذك لقطة زمنية محفوظة على الجهاز نفسه.

5. قرص خارجي بين أنظمة مختلفة

هنا يصبح exFAT الخيار العملي والأوحد تقريباً عندما تكون الأولوية القصوى هي التوافق السلس بين Linux و Windows و macOS والأجهزة الأخرى.

لكنه ليس بديلاً مثالياً لنظام ملفات لينكس الرئيسي. فهو لا يدعم نموذج صلاحيات لينكس (Permissions)، ولا يملك سجل عمليات (Journaling) يحمي من فساد البيانات عند الفصل المفاجئ. دوره مختلف تماماً: إنه جسر تواصل عالمي لنقل الملفات، وليس بيئة عمل.

6. الأجهزة المضمنة وذاكرة الفلاش (Embedded & Flash)

في الأنظمة المضمنة (الأجهزة المصممة لمهام محددة مثل أجهزة التوجيه أو الأنظمة الصناعية)، لا توجد إجابة واحدة تناسب الجميع. قد يكون ext2 مناسباً في بيئات بسيطة جداً لا تتطلب Journaling، بينما صُمم F2FS (Flash-Friendly File System) خصيصاً مع مراعاة خصائص وسلوك ذواكر الفلاش الحديثة.

🛠️ لا ينبغي اختزال الأمر في قاعدة مبسطة تقول إن “غياب الـ Journaling يطيل عمر ذاكرة الفلاش”. عمر الفلاش يتأثر بعوامل معقدة تشمل خوارزميات تسوية الاهتراء (Wear Leveling)، وجودة وحدة التحكم في الذاكرة، ونمط الكتابة الفعلي. في هذه الفئة، يجب اختيار نظام الملفات بناءً على العتاد المحدد والحمل الفعلي، وليس بناءً على قواعد عامة.