مقدمة إلى نظام ملفات لينكس EXT4

سنتعلم في هذا الدرس، بعض المعلومات عن تاريخ نظام ملفات EXT4 وعن ميزاته واستخدامه الأمثل، وسنناقش الاختلافات بينه وبين الإصدارات السابقة من أنظمة ملفات EXT.
أريد في هذا الدرس تفصيل مواصفات أنظمة ملفات EXT، لكنني سأبدأ أولًا بالإجابة على التساؤل «ما هو نظام الملفات»، نظام الملفات يقوم بما يلي:

1. تخزين البيانات: إذ إنَّ الغرض الرئيسي لأي نظام ملفات هو توفير مكان منظم ومُهيكل لتخزين البيانات والحصول عليها.
2. توفير مجالات أسماء (namespaces): إذ يوفر نظام الملفات منهجية تنظيمية لتسمية وهيكلة البيانات.
3. توفير نموذج أمني (security model): الذي يُعرِّف امتيازات الوصول إلى البيانات المخزنة.
4. توفير واجهة برمجية (API): وهي الدوال (functions) التي تستخدم لتتعامل مع الكائنات الموجودة في نظام الملفات مثل المجلدات والملفات.
5. توفير برمجيات لتطبيق المواصفات السابقة.

سنركِّز في درسنا على أوّل عنصر من القائمة السابقة ونستكشف بنى البيانات الوصفية (metadata) التي توفر إطار العمل المنطقي (logical framework) لتخزين البيانات في أنظمة ملفات EXT.

تاريخ نظام ملفات EXT

صحيحٌ أنَّ نظام ملفات EXT قد كُتِبَ لأنظمة لينكس، لكن جذوره تتأصل في نظام تشغيل Minix ونظام ملفاته، والذي يسبق ظهور لينكس بخمس سنوات، إذ نُشِر أوّل مرة في عام 1987.
سيسهل علينا فهم نظام ملفات EXT4 إذا نظرنا نظرةً شموليةً على تاريخ نظام ملفات EXT والتطور التقني الذي حدث لعائلة أنظمة ملفات EXT بدءًا من أصولها في نظام Minix.

نظام ملفات Minix

عندما كان Linus Torvalds يكتب نواة لينكس، احتاج إلى نظام ملفات لكنه لم يرغب بكتابة واحد، لذا ضمّن نظام ملفات Minix الذي كتبه Andrew S. Tanenbaum وكان جزءًا من نظام تشغيل Minix؛ والذي هو نظام تشغيل شبيه بِيونكس (Unix-like) كُتِبَ لأغراضٍ تعليمية، وكانت شيفرته المصدرية متوافرة مجانًا ومرخصة برخصة سمحت بتضمينها في أوّل نسخة من نواة لينكس.
هذه هي بنية نظام ملفات Minix، والتي تتواجد أغلبية مكوناتها في القسم (partition) الذي يستعمل نظام الملفات السابق:

• قطاع الإقلاع (boot sector) الموجود في أوّل قطاع (sector) في القرص الصلب الذي يحتوي على نظام الملفات؛ يحتوي قطاع الإقلاع على سجل إقلاع صغير جدًا إضافةً إلى جدول الأقسام (partition table).
• أوّل قطاع في كل قسم يسمى قطاع superblock، الذي يحتوي على البيانات الوصفية التي تُعرِّف البنى الأخرى الموجودة في نظام الملفات وتحدد مكانها في القرص الفيزيائي.
• قطاع بقائمة مؤشرات الفهرسة (inode)، التي تحدد ما هي مؤشرات الفهرسة المستخدمة والمتاحة للاستخدام.
• مؤشرات الفهرسة، التي لها مساحة خاصة على القرص، وكل مؤشر فهرسة يملك معلومات عن ملف واحد، بما في ذلك مكان كتل البيانات (data blocks)، أي ما هي المناطق على القرص التي ترتبط بهذا الملف.
• قائمة بالمناطق (zone bitmap)، والتي تَتَبَّع مناطق البيانات المستخدمة والحرة.
• منطقة تخزين البيانات (date zone)، وهي مكان تخزين البيانات.

سُيستعمل –لكلا نوعَي القوائم السابقين– بت (bit) وحيد لتمثيل منطقة بيانات أو مؤشر فهرسة واحد؛ فإذا كانت قيمة البت تساوي الصفر فهذا يعني أنَّ منطقة التخزين أو مؤشر الفهرسة حر ويمكن استخدامه، أما إذا كانت قيمة البت تساوي الواحد فهذا يعني أنَّ منطقة البيانات أو مؤشر الفهرسة قيد الاستخدام.
حسنًا، ما هو «مؤشر الفهرسة» (inode)، إنه اختصارٌ للكلمة index-node، إذ إنَّ مؤشر الفهرسة هو كتلة موجودة على القرص مساحتها 256 بايت التي تخزِّن بيانات تصف الملف.
هذه البيانات تتضمن حجم الملف، ومُعرِّف المستخدم (user ID) للمستخدم المالك للملف وللمجموعة المالكة، إضافةً إلى نمط الملف (أي أذونات الوصول)؛ مع تخزين ثلاث بصمات وقت (timestamps) التي تُحدِّد ما هو الوقت والتاريخ الذي تم الوصول إلى الملف آخر مرة، ومتى عُدِّل، ومتى تغيّرت البيانات الموجودة في مؤشر الفهرسة آخر مرة.
يحتوي مؤشر الفهرسة على معلومات تُشير إلى مكان تخزين بيانات الملف على القرص الصلب، وهذه المعلومات هي قائمة بمناطق البيانات (أو كتل البيانات) في أنظمة ملفات Minix و EXT1-3.
كان مؤشر الفهرسة في نظام ملفات Minix يدعم تخزين تسع كتل بيانات، سبعٌ منها مباشر واثنان ليستا مباشرتين؛ إذا أردت تعلم المزيد عن بنية نظام ملفات Minix فأنصحك بإلقاء نظرة على مستند PDF الآتي الذي يشرح ذلك بالتفصيل واقرأ لمحةً عامةً عن بنية مؤشرات الفهرسة في ويكيبيديا.

EXT

نظام الملفات EXT الأصلي (الذي يرمز اسمه إلى Extended) كتبه Rémy Card ونُشِرَ مع نواة لينكس في عام 1992 لتجاوز بعض محدوديات التخزين في نظام ملفات Minix، وكانت التغيرات البنيوية الرئيسية حدثت للبيانات الوصفية لنظام الملفات، والتي أصبحت مبنية على نظام ملفات Unix ‏(UFS)، والذي أصبح معروفًا بنظام ملفات FFS (اختصار للعبارة Berkeley Fast File System).
وجدتُ قدرًا ضئيلًا من المعلومات المنشورة عن نظام ملفات EXT التي يمكن التأكد منها، وأرجِّح ذلك بسبب المشاكل الكبيرة التي كان يواجهها هذا النظام، ولأن نظام ملفات EXT2 استبدله بعد فترةٍ قليلة.

EXT2

نظام ملفات EXT2 كان ناجحًا جدًا، إذ استعمل في توزيعات لينكس لسنواتٍ عدِّة، وكان أوّل نظام ملفات تعاملتُ معه عندما بدأت باستخدام Red Hat Linux 5.0 في عام 1997.
كان نظام ملفات EXT2 يملك بنية البيانات الوصفية الموجودة في نظام ملفات EXT نفسها، لكن نظام ملفات EXT2 كان متطلعًا للمستقبل، إذ ترك مساحةً كبيرةً بين بنى البيانات الوصفية لاستخدامها مستقبلًا.
وكما في نظام ملفات Minix، امتلك EXT2 قطاع إقلاع في أوّل قطاع موجود على القرص الصلب الذي ثُبِّتَ عليه، والتي يحتوي على سجل إقلاع صغير جدًا وجدول أقسام، وكانت هنالك مساحة محجوزة بعد قطاع الإقلاع، والتي تمتد من قطاع الإقلاع إلى أوّل قسم في القرص الصلب. يستعمل مُحمِّل الإقلاع GRUB2 (أو GRUB1) هذه المساحة لتخزين شيفرة الإقلاع الخاصة به.
المساحة الموجودة في كل قسم EXT2 تُقسَّم إلى مجموعات أسطوانية (cylinder groups) التي تسمح بإدارة جزيئية (granular management) للمساحة التخزينية. تُظهِر الصورة التالية البنية الأساسية للمجموعات الأسطوانية (والتي تكون مساحة كل واحدة منها –حسب خبرتي– حوالي 8 ميغابايت)، تذكر أنَّ واحدة تخزين البيانات في الأسطوانة هي الكتلة، والتي تساوي 4 كيلوبايت تقريبًا.

أوّل قطاع في المجموعة الأسطوانية يسمى قطاع superblock، الذي يحتوي على البيانات الوصفية التي تُعرِّف البنى الأخرى التابعة لنظام الملفات وتحدد مكانها في القرص الفيزيائي.
يمكن استبدال قطاع superblock معطوب باستخدام أدوات التعامل مع الأقراص مثل dd، وذلك باستعادة محتويات نسخة احتياطية من قطاع superblock، ولا يحدث ذلك عادةً، لكن منذ عدِّة سنوات حدث ذلك معي، واستطعت استعادة محتويات قطاع superblock من إحدى النسخ الاحتياطية، ولحسن الحظ كنتُ محتاطًا لهذا الأمر واستعملتُ الأمر dumpe2fs للحصول على بيانات الأقسام الموجودة في نظامي.
ما يلي هو جزء من ناتج الأمر dumpe2fs، الذي يُظهِر البيانات الوصفية الموجودة في قطاع superblock، إضافةً إلى بيانات عن أوّل مجموعتين أسطوانيتين في نظام الملفات:

# dumpe2fs /dev/sda1
Filesystem volume name:   boot 
Last mounted on:          /boot 
Filesystem UUID:          79fc5ed8-5bbc-4dfe-8359-b7b36be6eed3 
Filesystem magic number:  0xEF53 
Filesystem revision #:    1 (dynamic) 
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir nlink extra_isize 
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl 
Filesystem state:         clean 
Errors behavior:          Continue 
Filesystem OS type:       Linux 
Inode count:              122160 
Block count:              488192 
Reserved block count:     24409 
Free blocks:              376512 
Free inodes:              121690 
First block:              0 
Block size:               4096 
Fragment size:            4096 
Group descriptor size:    64 
Reserved GDT blocks:      238 
Blocks per group:         32768 
Fragments per group:      32768 
Inodes per group:         8144 
Inode blocks per group:   509 
Flex block group size:    16 
Filesystem created:       Tue Feb  7 09:33:34 2017 
Last mount time:          Sat Apr 29 21:42:01 2017 
Last write time:          Sat Apr 29 21:42:01 2017 
Mount count:              25 
Maximum mount count:      -1 
Last checked:             Tue Feb  7 09:33:34 2017 
Check interval:           0 (<none>) 
Lifetime writes:          594 MB 
Reserved blocks uid:      0 (user root) 
Reserved blocks gid:      0 (group root) 
First inode:              11 
Inode size:               256 
Required extra isize:     32 
Desired extra isize:      32 
Journal inode:            8 
Default directory hash:   half_md4 
Directory Hash Seed:      c780bac9-d4bf-4f35-b695-0fe35e8d2d60 
Journal backup:           inode blocks 
Journal features:         journal_64bit 
Journal size:             32M 
Journal length:           8192 
Journal sequence:         0x00000213 
Journal start:            0 
 
 
Group 0: (Blocks 0-32767) 
 Primary superblock at 0, Group descriptors at 1-1 
 Reserved GDT blocks at 2-239 
 Block bitmap at 240 (+240) 
 Inode bitmap at 255 (+255) 
 Inode table at 270-778 (+270) 
 24839 free blocks, 7676 free inodes, 16 directories 
 Free blocks: 7929-32767 
 Free inodes: 440, 470-8144 
Group 1: (Blocks 32768-65535) 
 Backup superblock at 32768, Group descriptors at 32769-32769 
 Reserved GDT blocks at 32770-33007 
 Block bitmap at 241 (bg #0 + 241) 
 Inode bitmap at 256 (bg #0 + 256)
 Inode table at 779-1287 (bg #0 + 779) 
 8668 free blocks, 8142 free inodes, 2 directories 
 Free blocks: 33008-33283, 33332-33791, 33974-33975, 34023-34092, 34094-34104, 34526-34687, 34706-34723, 34817-35374, 35421-35844, 35935-36355, 36357-36863, 38912-39935, 39940-40570, 42620-42623, 42655, 42674-42687, 42721-42751, 42798-42815, 42847, 42875-42879, 42918-42943, 42975, 43000-43007, 43519, 43559-44031, 44042-44543, 44545-45055, 45116-45567, 45601-45631, 45658-45663, 45689-45695, 45736-45759, 45802-45823, 45857-45887, 45919, 45950-45951, 45972-45983, 46014-46015, 46057-46079, 46112-46591, 46921-47103, 49152-49395, 50027-50355, 52237-52255, 52285-52287, 52323-52351, 52383, 52450-52479, 52518-52543, 52584-52607, 52652-52671, 52734-52735, 52743-53247 
 Free inodes: 8147-16288 
Group 2: (Blocks 65536-98303) 
 Block bitmap at 242 (bg #0 + 242) 
 Inode bitmap at 257 (bg #0 + 257) 
 Inode table at 1288-1796 (bg #0 + 1288) 
 6326 free blocks, 8144 free inodes, 0 directories 
 Free blocks: 67042-67583, 72201-72994, 80185-80349, 81191-81919, 90112-94207 
 Free inodes: 16289-24432 
Group 3: (Blocks 98304-131071)
 
<snip>

كل مجموعة أسطوانية لها قائمة مؤشرات الفهرسة الخاصة بها التي تستخدم لتحديد ما هي مؤشرات الفهرسة المستعملة والحرة في تلك المجموعة. تملك مؤشرات الفهرسة مساحةً خاصةً لها في كل مجموعة، وكل مؤشر فهرسة يحتوي على معلومات عن ملفٍ وحيد، بما في ذلك مكان كتل البيانات التي تتعلق بذاك الملف.
أما قائمة الكتل فتَتَبّع كتل البيانات الحرة والمستخدمة ضمن نظام الملفات؛ لاحظ وجود قدر كبير من البيانات حول نظام الملفات في الناتج السابق، وستكون معلومات المجموعات طويلةً جدًا في أنظمة الملفات الكبيرة؛ إذ تتضمن البيانات الوصفية الخاصة بالمجموعة الأسطوانية قائمةً بجميع كتل البيانات الحرة فيها.
يُطبِّق نظام ملفات EXT استراتيجيات لتوزيع البيانات التي تحرص على تقليل تجزئة الملف قدر المستطاع، وتقليل التجزئة سيُحسِّن من أداء نظام الملفات، وهذه الاستراتيجيات مشروحة في قسم EXT4 أدناه.
أكبر مشكلة مع نظام ملفات EXT2 –التي واجهتني في بعض المناسبات– هي الزمن الطويل الذي يقدر بالساعات لاستعادة نظام الملفات بعد حدوث انهيار مفاجئ، لأنَّ برنامج fsck (اختصار للعبارة file system check) كان يأخذ وقتًا طويلًا للعثور على التضاربات في نظام الملفات وتصحيحها.
ففي إحدى المرات أخذت استعادة القرص في أحد حواسيبي بعد حدوث انهيار ما يزيد عن 28 ساعة، وكان حجم الأقراص آنذاك قليلًا ويقدر ببضع مئات من الميغابايتات.

EXT3

كان لنظام ملفات EXT3 هدفٌ وحيدٌ ألا وهو التغلب على مشكلة استغراق الأمر fsck وقتًا طويلًا لاستعادة بنية القرص المعطوبة بسبب حدوث إغلاق غير سليم الذي وقع أثناء عملية تحديث لأحد الملفات، فالتغيير الوحيد الذي طرأ على نظام ملفات EXT هو إضافة السجلات أو الصحائف (journal) التي تُخزِّن التعديلات مسبقًا قبل إجرائها على نظام الملفات؛ أما بقية بنية القرص فبقيت تماثل بنية نظام ملفات EXT2.
بدلًا من كتابة البيانات إلى كتل البيانات على القرص مباشرةً كما في الإصدارات السابقة، فإن السجلات في نظام ملفات EXT3 تكتب بيانات الملف –إضافةً إلى البيانات الوصفية– إلى مكان مُحدَّد في القرص، وبعد أن تكتب البيانات بأمان على القرص، فيمكن أن تُدمَج أو تُضاف إلى الملف الهدف باحتمال فقدان البيانات بنسبة تقترب من الصفر.
وبعد كتابة البيانات إلى كتل البيانات على القرص، فسيُحدَّث السجل (journal) لكي يبقى نظام الملفات بحالة مستقرة في حال حدوث فشل في النظام قبل كتابة جميع البيانات الموجودة في السجل على القرص.
سيتحقق نظام الملفات من وجود تضاربات عند الإقلاع، وستُكتَب البيانات الموجودة في السجل إلى كتل البيانات الموجودة في القرص لإكمال التحديثات التي تستهدف ملفًا معينًا.
يُنقِص استخدام السجلات من أداء كتابة البيانات، لكن هنالك ثلاثة خيارات متوافرة للسجلات التي تسمح للمستخدم بالاختيار بين الأداء وسلامة البيانات والحماية. أفضِّل سلامة البيانات على الأداء في الأنظمة التي أعمل عليها لعدم وجود نشاطات تحتوي على الكثير من الكتابة على الأقراص.
تقلل ميزة السجلات من الوقت اللازم لتفحص القرص الصلب والبحث عن التضاربات بعد حدوث انهيارات من ساعات (أو حتى أيام) إلى دقائق قليلة (في أقصى الحالات).
واجهتُ مشاكل كثيرة على مر السنين التي أدت إلى انهيار أنظمتي؛ لن أذكرها بالتفصيل لأن ذكرها سيتطلب كتابة مقالة كاملة، لكن يكفي القول أنَّ أغلبها قد حدث دون تدخل من المستخدم، كحدوث انقطاع في الكهرباء؛ ولحسن الحظ، قلَّلت أنظمة ملفات EXT التي تستعمل السجلات من زمن الاستعادة إلى حوالي الدقيقتين أو ثلاث دقائق؛ أضف إلى ذلك أنَّني لم أواجه مشاكل مع فقدان البيانات منذ استعمالي لنظام ملفات EXT3.
ميزة السجلات الموجودة في EXT3 يمكن تعطيلها وسيعمل نظام الملفات مثل EXT2، لكن سيبقى السجل موجودًا إلا أنه فارغٌ وغير مستعمل. كل ما عليك فعله هو إعادة وصل (remount) القسم باستخدام الأمر mount مع تمرير خيار له لتحديد نوع نظام الملفات إلى EXT2. قد تتمكن من فعل ذلك من سطر الأوامر، اعتمادًا على نظام الملفات الذي تعمل عليه، لكن يمكنك تعديل الراية type في ملف ‎/etc/fstab ثم تعيد إقلاع النظام. لا أنصحك بتاتًا بإعادة وصل نظام ملفات EXT3 كنظام ملفات EXT2 لأن ذلك سيجعل نظام ملفاتك عرضةً لفقدان البيانات وستأخذ عملية استعادته وقتًا أطول.
يمكن تحديث نظام ملفات EXT2 موجود مسبقًا إلى EXT3 بإضافة سجل (journal) باستعمال الأمر الآتي:

tune2fs -j /dev/sda1

حيث ‎/dev/sda1 هو مُعرِّف القرص والقسم الذي تريد تحديثه؛ احرص على تعديل نوع نظام الملفات عبر تعديل قيمة الراية type في ملف ‎/etc/fstab وإعادة وصل ذاك القسم أو إعادة إقلاع النظام لتأخذ التعديلات مجراها.

EXT4

يُحسِّن نظام ملفات EXT4 من الأداء والموثوقية والقدرة التخزينية. فلتحسين الموثوقية (reliability) أضيفت بيانات وصفية وتدقيق لمجموع السجلات (journal checksums)؛ ولتحقيق متطلبات أنظمة المهام الحرجة (mission-critical) فتم تحسين بصمات الوقت لنظام الملفات لجعلها تُخزِّن بدقة تصل إلى النانو ثانية، وحُلَّت مشكلة «عام 2038» حتى عام 2446.
تحولت آلية حجز البيانات من كتل ثابتة الحجم إلى امتدادات (extents)، إذ يمكن وصف الامتداد بأنه بداية ونهاية مكان موجود على القرص الصلب، وهذا يجعل من الممكن توصيف ملفات طويلة ومستمرة (فيزيائيًا) في مؤشر فهرسة وحيد، والذي يقلل عدد المؤشرات المطلوبة لوصف مكان تخزين جميع البيانات في الملفات الكبيرة؛ ويُطبِّق نظام ملفات EXT4 استراتيجيات لتوزيع البيانات التي تحرص على تقليل تجزئة الملف قدر المستطاع.
يُقلِّل نظام ملفات EXT4 من تجزئة الملفات عبر جعل الملفات المُنشَأة حديثًا منتشرةً على القرص وليست متجمعةً في مكانٍ وحيدٍ في بداية القرص كما كانت تفعل أنظمة الملفات القديمة.
تحاول خوازميات حجز مساحة الملفات أن تخزن الملفات بانتظام قدر الإمكان على المجموعات الأسطوانية، وإذا كان من الضرورية تجزئة الملف فستحاول جعل تلك القطع قريبةً من بعضها فيزيائيًا لتقليل زمن التأخير الناتج عن حركة رأس القراءة.
هنالك استراتيجيات أخرى تستعمل لحجز مساحة تخزينية أكبر من اللازمة عند إنشاء الملفات الجديدة أو إضافة بيانات إلى ملفات موجودة مسبقًا، وهذا يساعد في زيادة مساحة الملف دون تجزئته إلى أكثر من جزء؛ أضف إلى ذلك أنَّ الملفات الجديدة لا توضع مباشرةً بعد الملفات الموجودة مسبقًا مما يمنع تجزئة الملفات الموجودة مسبقًا.
وبوضع مكان التخزين على القرص الفيزيائي جانبًا: يستعمل نظام الملفات EXT4 عدِّة استراتيجيات مثل تأخير حجز المساحة للسماح لنظام الملفات بجمع جميع البيانات التي ستكتب على القرص قبل حجز المساحة التخزينية لها، مما يُحسِّن من احتمال حجز مساحة تخزينية متجاورة أو مستمرة.
يمكن أن توصل (mount) أنظمة ملفات EXT القديمة مثل EXT2 و EXT3 كنظام ملفات EXT4 لتحسين الأداء قليلًا، لكن هذا يعني تعطيل بعض من أهم الميزات الجديدة لنظام ملفات EXT4، لذا لا أستحسن فعل ذلك.
أصبح نظام ملفات EXT4 افتراضيًا في توزيعة فيدورا بدءًا من الإصدار 14؛ ويمكن تحديث نظام ملفات EXT3 إلى EXT4 باتباع التعليمات الواردة في توثيق فيدورا، لكن لن يكون الأداء ممتازًا بسبب بنى البيانات الوصفية لنظام EXT3 التي ما تزال موجودةً؛ وأفضل طريقة برأيي لتحديث نظام ملفات EXT3 إلى EXT4 هي أخذ نسخة احتياطية لجميع البيانات في القسم الذي تحاول ترقية نظام ملفاته، ثم استخدام الأمر mkfs لإنشاء نظام ملفات EXT4 فارغ في القسم، ثم استعادة جميع البيانات من نسخة احتياطية.

inode

مؤشر الفهرسة –كما شرحناه سابقًا– هو مكوِّن مهم من البيانات الوصفية في أنظمة EXT، يُظهِر الشكل الآتي العلاقة بين مؤشر الفهرسة وبين البيانات المخزنة على القرص الصلب، وفي هذه الحالة كانت البيانات مجزئة، لذا من غير المرجح أن تشاهد ملفًا موزعًا على كتل بيانات كثيرة، وفي الحقيقة تجزئة الملفات في أنظمة ملفات EXT قليلة جدًا كما سترى في بقية هذا القسم، لذا ستستخدم أغلبية مؤشرات الفهرسة مؤشرًا أو مؤشرين مباشرين إلى البيانات ولن تستعمل أيّة مؤشرات غير مباشرة.

لا يحتوي مؤشر الفهرسة على اسم الملف، فالوصول إلى الملف يتم عبر قيود المجلد (directory entry)، وقيمة ذلك المؤشر هي رقم مؤشر الفهرسة، وكل مؤشر فهرسة في نظام الملفات له مُعرِّف ID ذي رقم فريد، لكن يمكن لمؤشرات الفهرسة الموجودة في أقسام أخرى على القرص الفيزيائي نفسه أو على الحاسوب نفسه أن تملك المعرف الفريد ذاته. وهذا ما يؤثر على الوصلات الصلبة (hard links)، لكن هذا النقاش خارج عن نطاق هذا الدرس.
يحتوي مؤشر الفهرسة على البيانات الوصفية التابعة للملف، بما في ذلك نوعه والأذونات المسندة إليه وحجمه التخزيني، ويحتوي مؤشر الفهرسة على مساحة لخمسة عشر مؤشرًا التي تصف مكان وطول كتل البيانات الموجودة في قسم البيانات من المجموعة الأسطوانية، ويوفر اثنا عشر مؤشرًا منها وصولًا مباشرًا إلى كتل البيانات ويجب أن تكون كافيةً للتعامل مع معظم الملفات؛ لكن للملفات المجزأة كثيرًا، فمن الضروري الحصول على إمكانيات إضافية على شكل مؤشرات غير مباشرة، ولا تعد هذه المؤشرات على أنها مؤشرات فهرسة (inode)، لذا سأطلق عليها مصطلح «مؤشر» (node) للتفريق بينهما.
المؤشر غير المباشر هو كتلة بيانات عادية في نظام الملفات التي تستخدم لوصف البيانات وليس لتخزين البيانات الوصفية، وبالتالي يمكن دعم أكثر من خمس عشرة مدخلةً (entries). فمثلًا، إذا كانت كتلة البيانات بحجم 4 كيلوبايت فيمكنها أن تدعم 512 مؤشرًا غير مباشر ذا 4 بايتات، مما يسمح باستعمال 12 مؤشرًا مباشرًا و 512 مؤشرًا غير مباشر = 524 مؤشرًا للملف الواحد. يجدر بالذكر أنَّ استعمال مؤشرين أو ثلاثة مؤشرات غير مباشرة هو أمرٌ مدعوم، لكن ليس من المرجح أن تصدف هذه الحالة معنا.

تجزئة البيانات

كانت تجزئة البيانات في أنظمة ملفات الحواسيب القديمة مثل FAT (بمختلف إصداراته) و NTFS مشكلةً كبيرةً تؤدي إلى أداء منخفض للأقراص، وأصبحت عملية إلغاء التجزئة محط أنظار الشركات وانتشرت برمجيات لإلغاء التجزئة تتراوح بين البرمجيات الفعالة جدًا إلى البرمجيات الشكلية.
أنظمة الملفات المستعملة في لينكس تستعمل استراتيجيات تساعد في تقليل تجزئة الملفات الموجودة في القرص الصلب وتقلل تأثير التجزئة عندما تحدث.
يمكنك استعمال الأمر fsck على أنظمة ملفات EXT للتحقق من حالة تجزئة نظام الملفات الكلية؛ فالمثال الآتي يتفحص مجلد المنزل لجهازي الشخصي، الذي كانت نسبة التجزئة فيه حوالي 1.5% فقط. احرص على تمرير المعامل ‎-n لأنه يمنع fsck من اتخاذ أي إجراء على نظام الملفات التي يتفحصه.

fsck -fn /dev/mapper/vg_01-home

أجريتُ بعض الحسابات النظرية لتحديد إذا ما كانت عملية إلغاء تجزئة القرص ستسبب في تحسين ملحوظ للأداء؛ وصحيحٌ أنني افترضت بعض الفرضيات، وأخذتُ بيانات أداء القرص من قرص جديد من نوع Westren Digital بسعة 300 غيغابايت ذي زمن تحريك بين المسارات يقدر بقيمة 2 ملي ثانية؛ وكان عدد الملفات في هذا الملف مساويًا لعدد الملفات الموجودة في نظام في اليوم الذي أجريتُ فيه هذه الحسابات، وافترضتُ نسبةً كبيرةً من الملفات المجزئة (20%) التي ستجرى عليها عمليات يوميًا.

أجريتُ عمليتَي حساب لزمن البحث الإضافي اليومي، مرةً اعتمادًا على زمن الانتقال من مسار إلى آخر، وهذه هي الحالة الشائعة لأغلبية الملفات بسبب استراتيجيات تخزين الملفات التي تستعملها أنظمة ملفات EXT؛ ومرةً أخذتُ زمن البحث الإضافي اليومي، وبهذا أكون قد أخذت أسوأ حالة بالحسبان.
وكما تلاحظ من الجدول السابق، إنَّ أثر التجزئة على أنظمة ملفات EXT الحديثة المستعملة على قرص صلب ذي أداءٍ متواضع هو أثرٌ ضئيل ويهمل لأغلبية حالات الاستخدام.
يمكنك أن تضع أرقامًا من نظامك في ورقة عمل (spreadsheet) لترى أثر التجزئة في نظامك على الأداء. وصحيحٌ أنَّ العمليات الحسابية السابقة لا تمثِّل الأداء الفعلي، لكن قد تعطيك نظرة عامة عن التجزئة الموجودة في نظام الملفات عندك وأثرها النظري على أداء النظام.
نسبة التجزئة في أغلبية الأقسام عندي تتراوح بين 1.5% إلى 1.6%؛ لكن لدي قسم نسبة تجزئته هي 3.3% لكنه قسمٌ كبيرٌ بسعة 128 غيغا بايت وفيه أقل من 100 ملف ISO حجمها التخزيني كبير جدًا؛ وكان علي توسعة هذا القسم عدِّة مرات على مر الوقت لأنه كان ممتلئًا طوال الوقت.
لكن هنالك بعض بيئات العمل التي تتطلب ضمانةً لنسبة تجزئة أقل؛ ويمكن ضبط نظام ملفات EXT من مدير له خبرة ويمكنه تعديل المعاملات لتناسب نمط العمل الملائم. ويمكن فعل ذلك عند إنشاء نظام الملفات أو لاحقًا باستخدام الأمر tune2fs، ويجب أن تُختبَر نتائج كل عملية تعديل، وتُسجَّل النتائج وتُحلَّل للتأكد أنَّ الأداء مثالي في البيئة المستهدفة.
وفي أسوأ حالة، التي لا يمكن تحسين الأداء فيها إلى الدرجة المطلوبة، فيمكن أن تكون أنظمة الملفات الأخرى ملائمة لنوع الأعمال المطلوب؛ تذكر أنَّ من الشائع استخدام أكثر من نظام ملفات في حاسوب واحد.
بسبب النسبة الضئيلة من التجزئة في أغلبية أنظمة ملفات EXT، فليس من الضروري إجراء عملية إلغاء تجزئة؛ ولا توجد أداء آمنة لإلغاء التجزئة لأنظمة ملفات EXT؛ لكن هنالك عدِّة أدوات تسمح لك بالتحقق من تجزئة ملف معيّن أو تجزئة بقية المساحة الفارغة في نظام الملفات.
هنالك أداة باسم e4defrag التي تستطيع إلغاء تجزئة ملف أو مجلد أو نظام ملفات بما تسمح به المساحة الفارغة المتبقية، وكما يوحي اسم هذه الأداة: فهي تعمل على الملفات الموجودة على نظام ملفات EXT4، ولها بعض المحدوديات.
إذا كان من الضروري إجراء عملية إلغاء تجزئة كاملة لنظام ملفات EXT4، فهنالك طريقة وحيدة عملية ألا وهي نقل جميع الملفات من نظام الملفات الذي تريد إلغاء تجزئته، وتحرص على حذفها حذفًا تامًا بعد أن تُنسَخ بشكل آمن إلى مكانٍ آخر؛ ومن المستحسن زيادة مساحة القسم إن أمكن ذلك، لتجنب حدوث التجزئة مستقبلًا. يمكنك بعد ذلك أن تنسخ الملفات إلى القسم الجديد؛ يجدر بالذكر أنَّ الطريقة السابقة لا تضمن لك إلغاء التجزئة تمامًا.

الخلاصة

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

ترجمة –وبتصرّف– للمقال An introduction to Linux’s EXT4 filesystemلصاحبه David Both