البحث في الموقع

سنتعلم في هذا الدرس، بعض المعلومات عن تاريخ نظام ملفات EXT4 وعن ميزاته واستخدامه الأمثل، وسنناقش الاختلافات بينه وبين الإصدارات السابقة من أنظمة ملفات EXT. أريد في هذا الدرس تفصيل مواصفات أنظمة ملفات EXT، لكنني سأبدأ أولًا بالإجابة على التساؤل «ما هو نظام الملفات»، نظام الملفات يقوم بما يلي: تخزين البيانات: إذ إنَّ الغرض الرئيسي لأي نظام ملفات هو توفير مكان منظم ومُهيكل لتخزين البيانات والحصول عليها. توفير مجالات أسماء (namespaces): إذ يوفر نظام الملفات منهجية تنظيمية لتسمية وهيكلة البيانات. توفير نموذج أمني (security model): الذي يُعرِّف امتيازات الوصول إلى البيانات المخزنة. توفير واجهة برمجية (API): وهي الدوال (functions) التي تستخدم لتتعامل مع الكائنات الموجودة في نظام الملفات مثل المجلدات والملفات. توفير برمجيات لتطبيق المواصفات السابقة. سنركِّز في درسنا على أوّل عنصر من القائمة السابقة ونستكشف بنى البيانات الوصفية (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%) التي ستجرى عليها عمليات يوميًا. عدد الملفات الكلي 271,794 نسبة التجزئة 5.00% الانقطاعات 13,590 نسبة الملفات المجزئة التي ستجرى عليها عمليات يوميًا 20% (فرضًا) عدد حركات البحث الإضافية 2,718 متوسط زمن البحث 10.90 ملي ثانية زمن البحث الإضافي اليومي 29.63 ثانية 0.49 دقيقة زمن الانتقال من مسار إلى آخر 2.00 ملي ثانية زمن الانتقال الإضافي اليومي 5.44 ثانية 0.091 دقيقة أجريتُ عمليتَي حساب لزمن البحث الإضافي اليومي، مرةً اعتمادًا على زمن الانتقال من مسار إلى آخر، وهذه هي الحالة الشائعة لأغلبية الملفات بسبب استراتيجيات تخزين الملفات التي تستعملها أنظمة ملفات 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

مجموعات التحكم هي آلية في النواة لتجميع وتتبع ووضع حد لاستهلاك الموارد للمهام؛ الواجهة الإدارية التي توفرها النواة تكون عبر نظام ملفات وهمي؛ لكن طوِّرت أدوات إدارية لمجموعات التحكم ذات مستوى أعلى، بما فيها libcgroup و lmctfy. بالإضافة لذلك، هنالك دليل في freedesktop.org حول كيف يمكن أن تتعاون التطبيقات بأفضل طريقة باستخدام واجهة نظام الملفات لمجموعات التحكم (cgroup filesystem interface). في أوبنتو 14.04؛ أصبح مدير مجموعات التحكم (cgmanager) متوفرًا كأداة أخرى لإدارة واجهة cgroup؛ حيث هدفه هو الاستجابة لطلبات dbus من أي مستخدم، مما يمكِّنه من إدارة مجموعات التحكم التي أُسنِدَت إليه فقط. لمحة إن مجموعات التحكم (cgroups) هي الميزة التي تستعمل لتجميع المهام؛ حيث يكون تتبع الموارد ووضع حدود لها مُدارًا من أنظمة فرعية؛ إذ أنَّ الهيكلية (hierarchy) هي مجموعة من الأنظمة الفرعية الموصولة مع بعضها بعضًا؛ على سبيل المثال، إذا كانت الأنظمة الفرعية للذاكرة والأجهزة (devices) موصولة مع بعضها في ‎/sys/fs/cgroups/set1، فيمكن لأي مهمة في ‎/child1 أن تكون عرضةً للحدود الموافقة للنظامين الفرعيين السابقين. حيث تُشكِّل كل مجموعة من الأنظمة الفرعية الموصولة «هيكليةً» (مع استثناءات)؛ مجموعات التحكم التي تكون أولاد ‎/child1 تكون عرضةً للحدود المفروضة على ‎/child1، ويكون استهلاك الموارد محسوبًا على ‎/child1. الأنظمة الفرعية الموجودة تتضمن: cpusets: تبسيط إسناد مجموعة من المعالجات وعُقَد الذاكرة إلى مجموعات التحكم؛ فالمهام في مجموعة تحكّم فيها النظام الفرعي cpusets يمكن أن تستخدم المعالجات المُسنَدة إلى تلك المجموعة فقط. blkio: تحديد كتل الدخل/الخرج لكل مجموعة تحكم. cpuacct: توفير حساب الاستهلاك للمعالج لكل مجموعة تحكم. devices: التحكم في قدرة المهام على إنشاء أو استخدام عقد الأجهزة إما باستعمال قائمة بيضاء (whitelist) أو سوداء (blacklist). freezer: توفير طريقة «لتجميد» (freeze) و «تذويب» (thaw) مجموعات التحكم؛ لا يمكن جدولة (scheduled) مجموعات التحكم وهي مجمدة. hugetlb: تبسيط وضع حد لاستهلاك hugetlb لكل مجموعة تحكم. memory: السماح للذاكرة، وذاكرة النواة، وذاكرة التبديل (swap) بأن تُتَبَّع وتقيّد. net_cls: توفير واجهة لوضع علامات على الرزم الشبكية بناءً على مجموعة التحكم المُرسِلة؛ يمكن استعمال هذه العلامات لاحقًا باستخدام tc‏ (traffic controller) لإسناد أولويات للرزم الشبكية. net_prio: السماح بضبط أولوية بيانات التراسل الشبكي بناءً على مجموعة التحكم. cup: تمكين ضبط جدولة الخصائص على أساس مجموعة التحكم. pref_event: تفعيل نمط لكل معالج لمراقبة الخيوط (threads) لمجموعات تحكم معينة. يمكن إنشاء مجموعات تحكم مُسماة دون استخدام أنظمة فرعية معها، ويكون الغرض من ذلك هو تتبع العمليات؛ على سبيل المثال، يقوم systemd بذلك لتتبع خدماته وجلسات المستخدم. نظام الملفات تُنشَأ هيكلية بوصل نسخة من نظام ملفات مجموعة التحكم لكل نظام فرعي مُراد استخدامه كخيار للوصل؛ على سبيل المثال: mount -t cgroup -o devices,memory,freezer cgroup /cgroup1 وهذا ما سيُنشِئ هيكلية فوريًا مع الأجهزة ومجموعات التحكم للذاكرة موصولةً مع بعضها؛ ويمكن إنشاء مجموعة تحكم فرعية (child cgroup) باستخدام mkdir: mkdir /cgroup1/child1 يمكن نقل المهام إلى مجموعة التحكم الفرعية الجديدة بكتابة أرقام معرفات عملياتهم في ملف tasks أو cgroup.procs: sleep 100 echo $! > /cgroup1/child1/cgroup.procs يمكن الإدارة أيضًا عبر ملفات في مجلدات cgroup؛ على سبيل المثال، لتجميد جميع المهام في child1: echo FROZEN > /cgroup1/child1/freezer.state يمكن العثور على كمية كبيرة من المعلومات عن مجموعات التحكم وأنظمتها الفرعية في مجلد التوثيق cgroups في شجرة مصدر النواة. التفويض يمكن لملفات ومجلدات مجموعات التحكم أن تُملَك من مستخدمين غير المستخدم الجذر، مما يمكِّن تفويض (delegation) إدارة مجموعات التحكم؛ عمومًا، تُجبِر النواة القيود المفروضة على الهيكلية على الأولاد؛ على سبيل المثال، إن كانت مجموعة الأجهزة ‎/child1 لا تملك وصولًا للقرص الصلب، فلا تستطيع مجموعة التحكم ‎/child1/child2 إعطاء نفسها هذه الامتيازات. في أوبنتو 14.04، يوضع المستخدمون افتراضيًا في مجموعة من مجموعات التحكم التي يملكونها، مما يسمح لهم باحتواء المهام التي يشغلونها باستخدام مجموعات تحكم فرعية بأمان؛ تُستخدَم هذه الميزة عمليًا ويمكن الاعتماد عليها فمثلًا يمكن استخدامها لإنشاء حاوية LXC دون امتيازات. المدير مدير مجموعات التحكم (cgmanager) يوفر خدمة D-Bus للسماح للبرامج والمستخدمين بإدارة مجموعات التحكم دون الحاجة إلى معرفة أو وصول مباشر إلى نظام ملفات مجموعات التحكم. وللطلبات من المهام في نفس مجال الأسماء (namespace) للمدير، فيمكن للمدير إجراء التحققات الأمنية اللازمة للتأكد من شرعية تلك الطلبات؛ وللطلبات الأخرى، كتلك القادمة من مهمة في حاوية، فيجب القيام بطلبات D-Bus مُحَسَّنة؛ حيث يجب أن تُمرَّر معرفات process، و user، و group على شكل SCM_CREDENTIALS، لذلك يمكن للنواة ربط المعرفات إلى قيم المضيف العامة. ولتبسيط استخدام استدعاءات D-Bus من جميع المستخدمين، فيبدأ «وسيط مدير مجموعات التحكم» (cgproxy) تلقائيًا في الحاويات؛ حيث يقبل طلبات D-Bus قياسية من المهام في نفس مجال أسمائه، ثم يحوله إلى طلبات SCM D-Bus محسنة التي تُمرَّر بعد ذلك إلى cgmanager. مثال بسيط عن إنشاء مجموعة تحكم -التي ستُشغِّل تصريفًا (compile) يستهلك كثيرًا من طاقة المعالجة- سيكون كالآتي: cgm create cpuset build1 cgm movepid cpuset build1 $$ cgm setvalue cpuset build1 cpuset.cpus 1 make مصادر مشروع cgmanager مُستضاف في linuxcontainers.org. يمكن العثور على صفحة توثيق النواة هنا. ويمكن العثور على دليل freedesktop.org لاستخدام مجموعات التحكم هنا. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Control Groups.

إن eCryptfs هو نظام ملفات للتشفير متوافق مع معايير POSIX ومن فئة الشركات لنظام لينُكس؛ وبتشكيل طبقة فوق طبقة نظام الملفات، فإن eCryptfs يحمي الملفات بغض النظر عن نظام الملفات المُستخدَم أو نوع القسم ...إلخ. هنالك خيار أثناء التثبيت لتشفير قسم ‎/home، هذا سيضبط تلقائيًا كل شيء يحتاج له النظام لتشفير ووصل ذاك القسم. سنشرح هنا طريقة الضبط لتشفير ‎/srv باستخدام eCryptfs. استخدام eCryptfsأولًا، ثبِّت الحزم اللازمة، بإدخال الأمر الآتي من الطرفية: sudo apt-get install ecryptfs-utilsالآن صِل القسم الذي تريد تشفيره: sudo mount -t ecryptfs /srv /srvستُسأل الآن عن بعض التفاصيل حول كيفية تشفير البيانات. لاختبار أن الملفات الموجودة في ‎/srv هي مشفرة، فانسخ المجلد ‎/etc/default إلى ‎/srv: sudo cp -r /etc/default /srvثم افصل القسم ‎/srv، وحاول عرض الملف: sudo umount /srv cat /srv/default/cronإعادة وصل ‎/srv باستخدام ecryptfs ستجعل البيانات قابلةً للعرض مرةً أخرى. وصل الأقسام المشفرة تلقائياهنالك طريقتان لوصل نظام ملفات مُشفَّر باستخدام ecryptfs أثناء الإقلاع؛ سيستخدم هذا المثال الملف ‎/root/.ecryptfsrc الذي يحتوي على خيارات الوصل، بالإضافة إلى ملف مرور موجود على قرص USB. أنشِئ أولًا الملف ‎/root/.ecryptfsrc الذي يحتوي على: key=passphrase:passphrase_passwd_file=/mnt/usb/passwd_file.txt ecryptfs_sig=5826dd62cf81c615 ecryptfs_cipher=aes ecryptfs_key_bytes=16 ecryptfs_passthrough=n ecryptfs_enable_filename_crypto=nملاحظة: عدِّل ecryptfs_sig إلى التوقيع في ‎/root/.ecryptfs/sig-cache.txt. ثم أنشِئ ملف المرور ‎/mnt/usb/passwd_file.txt: passphrase_passwd=[secrets]أضف الآن الأسطر الضرورية إلى ملف ‎/etc/fstab: /dev/sdb1 /mnt/usb ext3 ro 0 0 /srv /srv ecryptfs defaults 0 0تأكد أن قرص USB سيوصل قبل القسم المشفر. في النهاية، أعد الإقلاع ويجب أن يوصل ‎/srv باستخدام eCryptfs. أدوات أخرىالحزمة ecryptfs-utils تحتوي على أدواتٍ أخرى مفيدة: الأداة ecryptfs-setup-private تُنشِئ مجلد ‎~/Private الذي يحتوي على المعلومات المشفرة؛ يمكن تنفيذ هذه الأداة من المستخدمين العاديين للحفاظ على بياناتهم من المستخدمين الآخرين على النظام.الأداة ecryptfs-mount-private والأداة ecryptfs-umount-private ستصل أو تفصل مجلد ‎~/Private على التوالي وبالترتيب.ecryptfs-add-passphrase: إضافة عبارة مرور لما يسمى «kernel keyring».ecryptfs-manager: إدارة كائنات eCryptfs مثل المفاتيح.ecryptfs-stat: السماح لك بعرض معلومات eCryptfs الوصفية لملفٍ ما.مصادرللمزيد من المعلومات حول eCryptfs، راجع صفحة المشروع على Lanuchpad.هنالك مقالة في Linux Journal تشرح eCryptfs.للمزيد من خيارات eCryptfs، راجع صفحة الدليل man ecryptfs.لدى صفحة ويكي أوبنتو «eCryptfs» المزيد من التفاصيل.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: eCryptfs.