بواسطة Jeremy Reimer ترجمة : زاهر النوتكي
مرحبا HFS!
يتذكر معظم الناس نظام ماكنتوش عام 1984م مع نوع من الرومانسية الضبابية ، متناسيين القيود الضخمة للوحدة الأصلية. جاء نظام ماكنتوش بمحرك أقراص مرن منفرد في زمن اعتاد مستخدمي الحاسوب الشخصي فيه على استخدام الأقراص الصلبة . كان نظام الملفات الأصلي يطلق عليه نظام ملفات ماكنتوش Macintosh File System ويشار اليه بالاختصار : MFS ، وكانت سعته التخزينية 20mb و4096 ملف. وكان يحتوي على أدلة ولا يحتوي عليها في الوقت ذاته!! يستطيع المستخدم إنشاء مجلدات رسومية ويقوم بسحب الملفات داخلهن ، ولكن لن تظهر هذه المجلدات في مربعات حوار الفتح والحفظ ، وبدلا من ذلك ، يقوم النظام بتخزين كل المعلومات المتعلقة بالملف والمجلد ضمن "مجلد فارغ" والذي من شأنه أن يختفي في حالة تعديله بأي طريقة كانت ، ويمكن فقط أن يحل محله "مجلد فارغ" جديد. من الإمكان أن تصلح هذه الطريقة بالنسبة للاقراص المرنة ولكنها تباطؤ أداء الأقراص الصلبة. يمكن أن يكون اسم الملف بطول 63 حرف.
في عام 1985 استبدل نظام MFS بنظام يحوي على مجلدات ذو تسلسل هرمي مناسب. وبسبب هذا ، كان يطلق عليه نظام الملفات الهرمي Hierarchal File System أو HFS. لسبب ما ، كانت تقتصر تسمية الملفات على 31 حرف فقط ، والذي كان قصيرا بما فيه الكفاية ليكون مزعجا. ويتم تخزين بيانات الملف ، و المجلد والمساحة الفارغة في شجرة بيانات ثنائية B-Tree ، نوع من هيكلة التخزين الثنائية يسمح بفرز واسترجاع سريع للمعلومات المخزنة.
يستخدم نظام HFS عناقيد سعة 512 كيلوبايت مع مؤشر 16بت ، وبالتالي فإن الحجم الأقصى للقرص يعادل 32 جيابايت. تم مضاعفة حجم المؤشر ل32 بت في الاصدارات الحديثة مع امكانية الوصول لإثنين تيرابايت في المرة الواحدة.
أدخل كل من MFS و HFS طريقة مبتكرة لمعالجة الملفات تسمى الفروع "forks". فبدلا من تخزين البيانات الوصفية في مكان منفصل (مثلا مكان تخزين الأدلة) ، قام نظام HFS بتقسيم كل ملف إلى ملفين اثنين: الملف نفسه (فرع البيانات "data fork") وملف مخفي يسمى بـ(فرع الموارد "resource fork") والذي بدوره يحتوي على بيانات حول بنية الملف تتضمن معلومات حول الملف مثل أيقونته . تستخدم فروع الموارد لأكثر بكثير من البيانات الوصفية على سبيل المثال تحمل تفاصيل واجهة التطبيق وشفرة مصدرية قابل للتنفيذ في أجهزة ماكنتوش ما قبل PowerPC . كالسن في الشوكة ، تنتقل البيانات والموارد معا في كل الأوقات ، حتى يتم إرسال الملف إلى نوع آخر من أجهزة الحاسوب لا تعرف شيء عن الفروع. ولحسن الحظ ، كانت الأجهزة في تلك الفترة متغطرسة ونادرا ما تتحث لبعضها البعض ، فلذلك كان ذلك نادرا ما يمثل مشكلة.
بدلا من استخدام ثلاثة أحرف تافهة كلاحقة للملف لتحديد نوع الملف ، استخدم HFS لاحقة ضخمة مكونة من 4 أحرف "نوع الملف" و أخرى لمنشئ الملف ، و كانتا تخزن في بيانات الملف الوصفية ، وتعامل كمعاملة المعلومات الوصفية الأخرى كتاريخ إنشاء الملف مثلا.
لم يضيع نظام HFS وقته في استخدام كل من الشرطات والشرطات العكسية ليفرق بين أسماء المجلدات ، بل استخدم النقطتان (:) وتأكد بعد ذلك من عدم حصول البشر على أدنى فرصة في مشاهدة هذا الحرف في أي مكان في النظام ، حتى يحاولوا أن يدرجوها في اسم الملف.
لنترك المزاح جانبا ، يعتبر نظام HFS أول مثال في التاريخ يتم تصميمه خصيصا لملائمة احتياجات واجهة المستخدم الرسومية الجديدة آنذاك. كانت فلسفة تصميم واجهة المستخدم الرسومية لنظام ماكنتوش آنذاك إخفاء التفاصيل الغير مهمة عن المستخدم. كان يقصد من هذا التصميم "المتمحور حول البشر" هو مساعدة الناس على زيادة تركيزهم على عملهم بدل الانشغال بالتفاصيل التقنية لنظام الملفات.
وبطبيعة الحال ، لا شيء مثالي في هذه الحياة ، وكل النظم التي حاولت إخفاء التفاصيل التقنية بعيدا عن المستخدم ، عادة ما تتعارض مع ما اسماه جويل سبولسكي قانون التجريد المتسرب Law of Leaky Abstractions. حيث عندما يصاب شي بعطل ما مثل فقدان فرع الموارد عند إرسال الملف لجهاز حاسوب آخر وارجاعه مرة أخرى لنظام ماكنتوش ، لم يكن دائما واضحا ماذا ينبغي عمله لحل المشكلة.
يحوي نظام HFS بعض الحدود التقنية الأخرى التي من الممكن أن تتسرب من حين لآخر. حيث تخزن كل سجلات الملفات والأدلة في مكان واحد يسمى Catalog File ويستطيع برنامج واحد فقط الوصول لهذا الملف في كل مرة. وكانت هناك بعض الفوائد من هذا النهج ، كالبحث السريع عن الملفات. لم تكن أجهزة ماكنتوش الأولى تحوي على خاصية تعدد المهام ، ولذلك فان هذا لا يشكل مشكلة لمستخدمي ماكنتوش. ولكن عندما تم إضافة خاصية تعددية المهام في وقت لاحق ، سببت بعض المشاكل مع بعض البرامج حيث سببت بتوقف النظام "hogging the system." ويمكن أيضا أن يتسبب بتخريب ملف Catalog File وبالتالي يصبح نظام الملفات كاملا غير قابل للاستخدام. تقوم بعض أنظمة الملفات بتخزين معلومات الملفات والأدلة في أماكن منفصلة ، ولذلك حتى لو فسد مجلد واحد فإنه لن يؤثر على بقية النظام.
كما كان الحال بالنسبة للأنظمة الأخرى التي قمنا بتغطيتها لحد الآن ، كان عدد عناقيد النظام (تعرف بالمربعات blocks ) مثبت على رقم من 16 بت ، ولذلك لا يمكن أن يزيد عدد المربعات على 65535 في كل قسم من القرص ، مهما كان حجمه. يقوم نظام HFS (شأنه في ذلك شأن معظم نظم الملفات) بتخزين الملفات في مربعات مفردة ، لذلك كلما كان حجم المربعات كبيرا زادت المساحة الضائعة: فمثلا حتى ملف بحجم 1 كيلوبايت يلزمه مربع 16 كيلوبايت كامل على محرك أقراص بحجم 1GB. وتكون المشكلة أسوأ 8 مرات مع محرك أقراص سعة 8 جيجابايت ، وهلم جرا.
تم معالجة المشكلة الأخيرة مع نظام HFS+ من قبل شركة Apple عام 1998م ، الذي جاء مدمجا مع اصدارة نظام تشغيل ماك Mac OS 8.1. استخدم نظام عدد 32بت لترقيم المربعات ، كما سمح بأسماء ملفات لحد 255 حرف. على الرغم من أن إصدارات ماك تقليدية (9.2.2 وسابقاتها) تدعم 32 حرف فقط عند تسمية الملفات. وبصورة غريبة ، لم تدعم حزمة مايكروسوفت أوفيس المكتبية (اصدارة ماكنتوش) أكبر من 32 حرف عند تسمية ملفاتها حتى عام 2004م.
نظم ملفات أوميجا Amiga يحوي نظام أوميجا - أطلق بعد عام من أطلاق نظام ماكنتوش - على قدرات وسائط متعددة عالية بدت على أنها سابقة لأوانها بعقد من الزمن. ولكن وبسبب ضغوط الوقت لاطلاق نسخة نظام أوميجا الأصلية ، كان نظام الملفات واحد من أضعف أجزائه. حيث تم انتاجه من نظام TripOS - نظام تشغيلي تم تطويره من قبل MetaComCo-. كان يستخدم مربعات ذات حجم 512 كيلوبايت ، لكن كان يحتجز 24KB من كل مربع للبيانات الوصفية. أطلق مهندسو أوميجا على النظام اسم نظام ملفات قديم "OFS" ، والذين قاموا باستبداله بأسرع وقت ممكن.
تم اصدار FFS أو نظام الملفات السريع عام 1987م جنبا إلى جنب مع أوميجا 500 ،و 2000 ، ونظام أوميجا 1.3. وكان الفرق الرئيسي هو نقل البيانات الوصفية من كل مربع وتخزينها في مكان منفصل. ومثل نظام HFS ، كان يقتصر تسمية الملفات على 32 حرف.
ولدعم كل من نظام OFS و FFS أعيد تصميم نظام أوميجا التشغيلي ليقبل أنظمة ملفات متعددة في صيغة برنامج ملحق. وتم توثيق هذه الصيغة بحيث كان من مقدور أي شخص كتابة نظام ملفات خاص به حسب رغباته. وهناك الكثير من الناس من قاموا بذلك ، وكانت نتائج ذلك اصدار كل من نظام الملفات المحترف (PFS) و نظام الملفات الذكي (SFS) ، والتي لا تزال تستخدم من قبل مشجعي نظام أوميجا إلى يومنا هذا. وكان نظام Amiga OS4 التشغيلي لأوميجا بور بي سي يدعم أيضا بما يسمى FFS2 ، حيث تم إعادة كتابة كبيرة للنظام زاد من صعوبته أن شفرة التطبيق الأصلي غير قابل للنقل ، و أن توثيق طرق عمله الداخلية وتراكيب بياناته غير واضحة. أضاف نظام FFS2 القدرة على دعم تسمية الملفات لحد 105 حرف.
أنظمة ملفات لينكس و يونكس
نظام UFS
بدأ يونكس مشواره كدعابة على MULTICS - نظام صارم لتشراك الوقت متعدد المستخدمين ولا يحب أن يسخر منه أحد - ولكنه مضى ليترك منافسة الصارم في مزبلة التاريخ. كان نظام يونكس يسيطر بعناية على سوق عمل المحطات العلمية والخوادم قبل أن يحل محله نسخة مشابهة له في طريقة عمله تدعى لينكس ، والذي بدأ بدوره كدعابة على نظام يونكس. مغزى القصة هو أن الدعابات يمكن أن تكون أمور قوية.
وضع نظام يونكس على طول مشواره مجموعة من المعايير التي تحدد طرق تخزين ملفات المستخدمين. أصبح نظام ملفات يونكس (UFS) ، والذي كان يعرف أيضا نظام ملفات بيركلي السريع (Berkeley Fast File System) ، المعيار لنظم الملفات عندما قام باحثون من جامعة كاليفورنيا في بيركلي بتطوير نسخة محسنة من نظام ملفات يونكس الأصلي.
ظهر نظام يونكس للوجود من ثقافة الهاكر بدلا من القطاع التجاري ، لذلك جاء نظام الملفات انعكاسا لهذه النشأة. حيث يعتبر نظام يونكس حساسا لحالة الأحرف ، مما يعني أن README.TXT مختلف تماما عن ملف readme.txt والذي هو أيضا مختلف عن Readme.Txt. معظم النظم الأخرى تحافظ على حالة الأحرف عند تسمية الملف ، ولكن لا تهتم لكيفية وصول المستخدم لها. وعلى الرغم من هذا النظرة الغامضة لأسماء الملفات ، إلا أنها صمدت حتى يومنا هذا لأن تغييره الآن من شانه أن يعطل بعض البرامج التي تعتمد عليها. وفي بعض الأحيان ، يمكن لهذين العالمين التصادم بعنف : فنقل موقع انترنت من خادم ويندوز لخادم لينكس يمكن أن ينتج وصلات مقطوعة عندما يطلب الخادم وصلة some_file.htm مثلا وآخر شخص قام بتحرير الملف قام بحفظه باسم Some_File.htm بدلا من ذلك.
بعيدا عن التدقيق عن حالة الأحرف ، يكشف نظام الملفات جذوره كهاكر بطرق أخرى. يطلق على المؤشرات التي يستخدمها UFS لتحديد مكان الملفات على القرص اسم inodes ، وخلافا لنظم التشغيل الأخرى ، نظام يونكس سعيد جدا لاظهار بيانات هذه المؤشرات إلى المستخدم النهائي ، لم يكن نظام UFS يحوي ميزة السجلات (سجل بالتغييرات المراد تنفيذها على الملف) في بداية مشواره ، وبالتالي أي تحطم بالنظام أو انقطاع التيار الكهربائي يمكن أن يتلف بعض المؤشرات ويؤدي لفقدان بعض الملفات. وحل هذه المشكلة يتمثل في تشغيل أداة تدعى fsck (من File System Check التحقق من نظام الملفات) و مشاهدة النظام وهو يخبرك عن جميع أسراره القذرة عن المؤشرات!
كما هو الأمر في نظم الملفات الأخرى ، يتم تخزين الملفات في مكونات منفصلة تدعى مربعات blocks. استمر حجم المربع القياسي بالزيادة كلما زاد حجم الأقراص ، ولكنه وحد في النهاية على 8 كيلو بايت . لأن هذا الحجم الكبير من شأنه تبديد مساحة كبيرة من القرص الصلب. قام نظام BSD من تنفيذ خوارزمية ذكية تدعى block suballocation حيث تقوم بتجميع المربعات المملوءة جزئيا في واحد واحدة.
كما حاول نظام UFS التقليل من حركة رأس القرص الصلب من خلال تخزين الملفات والبيانات الوصفية قرب بعضها البعض ضمن مجموعات يطلق عليها الأسطوانات cylinders ومحاولة إبقاء كل الملفات ضمن مجلد واحد في أسطوانات متجاورة.
قام الكثير من بائعي نظام يونكس بتنفيذ نسختهم من UFS ، مما يجعلها في كثير من الأحيان تتعارض مع غيرها من الأنظمة. كما أضافت شركة صن Sun توثيقات لنسختها من النظام في Solaris 7 بينما قامت NeXT بإنشاء نسخة خاصة من UFS لنظام NeXTstep.
نظام ext2 استوحي نظام ext2 من تصميم UFS وهو في الأساس نسخة تعمل مثل نظام UFS مثلها في ذلك مثل كون نظام لينكس نسخة تعمل مثل نظام يونكس. وهذا ما سهل نقل العديد من من أدوات يونكس مثل أداة fsck ـ والتي تبدو قليلا مثل اللغة التجديفية عند قراءتها بالسرعة المناسبة. ومثل نظام UFS يفتقر نظام ext2 لسجلات التغييرات ولكن أيضا تجنب بعض اختبارات السلامة والتي قد تسرع من أداء النظام. وبسبب هذا ، كان من الضروري قول كلمة "fsck" مرارا وتكرارا.
كان لدى لينكس - والذي بدأ كمشروع هاوي عام 1991م ليحل محل نظام اندرو تاننبام التعليمي OS Minix - نسخة من نظام ملفات Minix ، ولكنها كانت تقتصر على 64 ميجابايت والذي تم استبدالها بسرعة بــext. تم تطوير ext2 عام 1993 لمعالجة بعض قيود النسخة الأصلية من نظام ext والتي ضلت على قد الحياة لعدة سنوات بعد ذلك. كان يحوي نظام ext2 على نفس نظام الاسطوانات "cylinder" مثل نظام UFS ولكن كان يطلق عليها اسم مجموع المربعات block groups بدلا من ذلك.
نظام ReiserFS بسبب افتقار نظام ext2 للسجلات ولأن لينكس مبني على روح المصادر المفتوحة ومساهمات الجميع ، كان هناك العديد من الناس من يريد أن يبني عالما أفضل من نظام ملفات لينكس. شخص واحد نجح فعلا وكان يدعى بهانز ريسر Hans Reiser وبسبب تواضعه الجم أسمى مشروعه باسمه ResierFS.
لم يضف ReiserFS التوثيق فحسب ولكن حاول تحسين جوانب أخرى كثيرة من نظام ext2. أدت كل من فهرسة B-Tree وروتينات المتقدمة للتخصيص للمربعات إلى اسراع نظام الملفات بشكل كبير ، خاصة عند التعامل مع الملفات الصغيرة الحجم على غرار ملفات 1KB.
نال ReiserFS على الكثير من الثناء وعلى دعم صناعي رئيسي من توزيعات لينكس مثل SuSE ، حتى بدأت العجلات بالسقوط لأسباب غير تقنية بالمقام الأول.
في البداية ، قرر هانز ريسر عدم مواصلة دعم وتحديث ReiserFS وتفضيل العمل على النظام الوريث المدعو Reiser4. كان أداء النسخة الجديدة جيدا ، ولكن لم يكن تحديثا نظيفا من ReiserFS ويتطلب من المستخدمين إعادة تهيئة القرص. وكانت هناك بعض التساؤلات حول موثوقية واستقرار نظام Reiser4 ، ولكن هذه النقاط كان يمكن أن تعالج في الوقت المناسب.
ما فاجأ المجتمع حقا هو شيء لا يمكن لأحد أن يتوقعه حيث وفي عام 2006م أُعلن عن فقدان زوجة هانز- نينا-. كما تم العثور على دم مطابق لحمضها النووي على حقيبة للنوم في سيارة هانز. ادعى هانز بأنه غير مذنب ، وحتى الآن لم تكتمل محاكمته الجنائية.
نظام ext3 قد بدأت شعبية ReiserFS بالتلاشي ، وبسبب الارتباك بحقيقة مستقبل ReiserFS ، فان العديد من مستخدميه انتقلوا للنظام الأكثر أمانا ext3 ، والذي هو أساسا ext2 مع إضافة خاصية التوثيق. وفي حين أنه من غير المرجح أن يفوز بسباق سرعة ،حافظ على تراث أسلافه في اختبار الموثوقية.
نظام JFS كان JFS مدخل شركة IBM للعبة نظام ملفات يونكس وقامت بإضافة السجلات لنظام UFS. حيث كان إعادة كتابة شفرة مفتوحة المصدر للنظام الملفات المملوك المستخدم من قبل AIX ، نسخة IBM الغريبة من نظام يونكس. استخدم نظام JFS الأشجار الثنائية لتسريع عملية الوصول إلى الملف ، كما أدخل فكرة التوسيعات extents ، والتي هي عبارة عن تجميعة ذات حجم 128 بايت من inodes. وهذا يحول دون قيام نظام الملفات من تخصيص كميات ثابته من مساحة القرص لـinodes كما كان يقوم به كل من ext2 و ext3.
نظام XFS جاء نظام XFS من نسخة سيليكون جرافيكس Silicon Graphics من يونكس ، والتي أطلق عليها Irix. قدمت لأول مرة عام 1994م مع Irix 5.3 ، وقد تم تصميمه من أجل السرعة والموثوقية ، كما كسب العديد من اختبارات مقارنة السرعة. كان نظام ملفات 64-بت بحد أقصى يبلغ 8 إكسابايت. كان يستخدم خاصية التوسعات ويحوي العديد من الميزات مثل تحسينه تعدد المهام ، حيث يمكن لعدة مهام أن تنفذ على نفس نظام الملفات في وقت واحد.
افرجت SGI عام 2000 عن الشفرة المصدرية لنظام XFS تحت رخصة GNU العامة ، وتم إضافة هذا النظام للعديد من توزيعات لينكس.
هذه المقالة تأتي في ثلاثة أجزاء: