ext3

يبلغ الحد الأقصى لعدد الكتل في نظام الملفات ext3 232. ^ويمكن أن يختلف حجم الكتلة، مما يؤثر على الحد الأقصى لعدد الملفات والحد الأقصى لحجم نظام الملفات: ^{[ 12 ]}

تتوفر ثلاثة مستويات من التسجيل في تطبيق نظام الملفات ext3 في لينكس:

مجلة (أقل المخاطر)

تُكتب كل من البيانات الوصفية ومحتويات الملفات في سجل العمليات قبل حفظها في نظام الملفات الرئيسي. ولأن سجل العمليات متصل نسبيًا على القرص، فإن ذلك يُحسّن الأداء إذا توفرت مساحة كافية فيه. أما في الحالات الأخرى، فيتدهور الأداء، لأن البيانات تُكتب مرتين: مرة في سجل العمليات، ومرة ​​في الجزء الرئيسي من نظام الملفات. ^{[ 13 ]}

تم الطلب (مخاطر متوسطة)

يتم تسجيل البيانات الوصفية فقط في سجل النظام؛ أما محتويات الملفات فلا تُسجل، ولكن يُضمن كتابة محتويات الملفات على القرص قبل وضع علامة "مُلتزم" على البيانات الوصفية المرتبطة بها في السجل. هذا هو الوضع الافتراضي في العديد من توزيعات لينكس. في حال انقطاع التيار الكهربائي أو حدوث عطل في نواة النظام أثناء كتابة ملف أو إضافة بيانات إليه، سيشير السجل إلى أن الملف الجديد أو البيانات المضافة لم تُلتزم، وبالتالي سيتم حذفها بواسطة عملية التنظيف. (وبالتالي، تتمتع الإضافات والملفات الجديدة بنفس مستوى حماية سلامة البيانات كما هو الحال في مستوى "التسجيل"). مع ذلك، قد تتلف الملفات التي يتم استبدالها لأن النسخة الأصلية من الملف لا تُخزن. لذا، من الممكن أن ينتهي الأمر بملف في حالة وسيطة بين الجديد والقديم، دون وجود معلومات كافية لاستعادة أي منهما (لم تصل البيانات الجديدة إلى القرص بالكامل، والبيانات القديمة غير مخزنة في أي مكان). والأسوأ من ذلك، قد تتداخل البيانات القديمة والجديدة في الحالة الوسيطة، لأن ترتيب الكتابة يعتمد على مكونات القرص. ^{[ 13 ] [ 14 ]}

إعادة الكتابة (أعلى المخاطر)

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

في جميع الأوضاع الثلاثة، يُضمن بقاء البنية الداخلية لنظام الملفات متسقة حتى بعد حدوث عطل. في جميع الأحوال، لن يتأثر سوى محتوى البيانات للملفات أو المجلدات التي كانت قيد التعديل عند تعطل النظام؛ أما الباقي فسيبقى سليماً بعد الاستعادة.

نظرًا لأن نظام الملفات ext3 يهدف إلى التوافق مع الإصدارات السابقة ext2، فإن العديد من هياكل البيانات على القرص تشبه تلك الموجودة في ext2. ونتيجة لذلك، يفتقر ext3 إلى الميزات الحديثة، مثل الامتدادات ، والتخصيص الديناميكي للعقد ، والتخصيص الفرعي للكتل . ^{[ 15 ]} يمكن أن يحتوي الدليل على 31998 دليلًا فرعيًا كحد أقصى ، لأن العقدة الواحدة يمكن أن تحتوي على 32000 رابط كحد أقصى (يزيد كل دليل فرعي مباشر عداد روابط العقدة في المجلد الأصل في مرجع "."). ^{[ 16 ]}

في نظام الملفات ext3، كما هو الحال في معظم أنظمة ملفات لينكس الحديثة، لا يُنصح باستخدام أداة النظام " fsck " أثناء تحميل نظام الملفات للكتابة. ^{[ 3 ]} فمحاولة فحص نظام ملفات مُحمّل بالفعل في وضع القراءة/الكتابة ستؤدي (على الأرجح) إلى اكتشاف تناقضات في بيانات تعريف نظام الملفات. وعندما تتغير بيانات تعريف نظام الملفات، وتُطبّق fsck التغييرات في محاولة لجعل بيانات التعريف "غير المتناسقة" متناسقة، فإن محاولة "إصلاح" هذه التناقضات ستؤدي إلى تلف نظام الملفات.

لا توجد أداة لإلغاء تجزئة الملفات ext3 عبر الإنترنت تعمل على مستوى نظام الملفات. يوجد برنامج لإلغاء تجزئة الملفات ext2 يعمل دون اتصال بالإنترنت e2defrag. مع ذلك، e2defragقد يؤدي هذا البرنامج إلى تلف البيانات، وذلك بحسب ميزات نظام الملفات المُفعّلة؛ فهو لا يدعم العديد من ميزات ext3 الحديثة. ^{[ 17 ]}

توجد أدوات لإلغاء تجزئة الملفات في مساحة المستخدم، مثل Shake ^{[ 18 ]} وdefrag ^{[ 19 ] [ 20 ]} . تعمل Shake بتخصيص مساحة للملف بأكمله كعملية واحدة، مما يدفع مُخصِّص المساحة عادةً إلى البحث عن مساحة قرص متجاورة. إذا كانت هناك ملفات تُستخدم في الوقت نفسه، فستحاول Shake كتابتها بجوار بعضها البعض. أما defrag فتعمل بنسخ كل ملف فوق نفسه. مع ذلك، لا تنجح هذه الاستراتيجية إلا إذا كان نظام الملفات يحتوي على مساحة حرة كافية. لا توجد أداة إلغاء تجزئة حقيقية لنظام الملفات ext3 ^{[ 21 ] .}

مع ذلك، وكما ورد في دليل مسؤول نظام لينكس، "تحافظ أنظمة ملفات لينكس الحديثة على التجزئة عند أدنى حد ممكن من خلال إبقاء جميع الكتل في الملف متقاربة، حتى لو لم يكن بالإمكان تخزينها في قطاعات متتالية. بعض أنظمة الملفات، مثل ext3، تُخصّص فعليًا الكتلة الحرة الأقرب إلى الكتل الأخرى في الملف. لذلك، ليس من الضروري القلق بشأن التجزئة في نظام لينكس." ^{[ 22 ]}

على الرغم من أن نظام الملفات ext3 مقاوم لتجزئة الملفات، إلا أنه قد يتعرض للتجزئة بمرور الوقت أو لأنماط استخدام محددة، مثل كتابة الملفات الكبيرة ببطء. ^{[ 23 ] [ 24 ]} ونتيجة لذلك، يحتوي نظام الملفات ext4 (النظام الذي خلف ext3) على أداة e4defrag لإلغاء تجزئة نظام الملفات عبر الإنترنت ^{[ 25 ]} ، ويدعم حاليًا الامتدادات (مناطق الملفات المتجاورة).

لا يدعم نظام الملفات ext3 استعادة الملفات المحذوفة. يقوم برنامج تشغيل ext3 بحذف الملفات بشكل فعال عن طريق مسح عقد الملفات ^{[ 26 ]} لأسباب تتعلق بسلامة النظام في حال حدوث أعطال.

لا تزال هناك عدة تقنيات ^{[ 27 ]} وبعض البرامج المجانية ^{[ 28 ]} والبرامج الاحتكارية ^{[ 29 ]} لاستعادة الملفات المحذوفة أو المفقودة باستخدام تحليل سجل نظام الملفات؛ ومع ذلك، فإنها لا تضمن استعادة أي ملف محدد.

e3compr ^{[ 30 ]} عبارة عن رقعة غير رسمية لنظام الملفات ext3 تُجري ضغطًا شفافًا . وهي نسخة مباشرة من e2compr، ولا تزال بحاجة إلى مزيد من التطوير. يتم تجميعها وتشغيلها بنجاح مع نواة النظام الأصلية ، ولكن خاصية التسجيل غير مُفعّلة بعد.

على عكس العديد من أنظمة الملفات الحديثة، لا يدعم نظام ext3 اللقطات بشكلٍ أصلي ، وهي القدرة على التقاط حالة نظام الملفات بسرعة في أي وقت. بدلاً من ذلك، يعتمد على لقطات على مستوى وحدة التخزين، وهي أقل كفاءة في استخدام المساحة، يوفرها نظام إدارة وحدات التخزين المنطقية (LVM) في لينكس . نظام الملفات Next3 هو نسخة معدلة من ext3 تدعم اللقطات، مع الحفاظ على التوافق مع تنسيق ext3 على القرص. ^{[ 31 ]}

لا يقوم نظام الملفات ext3 بإجراء التحقق من المجموع الاختباري عند الكتابة إلى سجل النظام. في جهاز تخزين مزود بذاكرة تخزين مؤقتة إضافية، إذا لم يتم تفعيل خيار ` barrier=1` كخيار ربط (في الملف `/etc/fstab` )، وإذا كان الجهاز يستخدم التخزين المؤقت للكتابة خارج الترتيب، فإن ذلك يُعرّض النظام لخطر تلف شديد في نظام الملفات أثناء حدوث عطل. ^{[ 32 ] [ 33 ] [ 34 ]} وذلك لأن أجهزة التخزين المزودة بذاكرة تخزين مؤقتة للكتابة تُبلغ النظام بأن البيانات قد كُتبت بالكامل، حتى لو كُتبت في ذاكرة التخزين المؤقتة (المتطايرة).

إذا تمت عمليات الكتابة على القرص الصلب بترتيب غير صحيح (بسبب قيام الأقراص الصلبة الحديثة بتخزين عمليات الكتابة مؤقتًا لتقليل زمن الاستجابة)، فمن المحتمل أن تتم كتابة كتلة الالتزام لإحدى المعاملات قبل كتابة الكتل الأخرى ذات الصلة. في حال انقطاع التيار الكهربائي أو حدوث عطل غير قابل للإصلاح قبل كتابة الكتل الأخرى، فسيتعين إعادة تشغيل النظام. عند إعادة التشغيل، سيعيد نظام الملفات تشغيل السجل كالمعتاد، وسيعيد تشغيل المعاملات "الفائزة" (المعاملات التي تحتوي على كتلة التزام، بما في ذلك المعاملة غير الصالحة المذكورة أعلاه، والتي تم وضع علامة عليها بكتلة التزام صالحة). وبالتالي، ستستمر عملية الكتابة غير المكتملة على القرص المذكورة أعلاه، ولكن باستخدام بيانات سجل تالفة. ونتيجة لذلك، سيقوم نظام الملفات عن طريق الخطأ بالكتابة فوق البيانات العادية ببيانات تالفة أثناء إعادة تشغيل السجل. لو تم استخدام مجاميع التحقق، حيث تم وضع علامة على كتل المعاملة "الفائزة الوهمية" بمجموع تحقق متبادل، لكان نظام الملفات قد تنبه لذلك ولم يُعد تشغيل البيانات التالفة على القرص. تمت إضافة ميزة التحقق من مجموع السجل إلى نظام الملفات ext4. ^{[ 35 ]}

قد لا تدعم أنظمة الملفات التي تمر عبر واجهة مُرَجِّع الأجهزة (بما في ذلك تطبيقات RAID وLVM البرمجية) خاصية الحواجز، وستصدر تحذيرًا عند استخدام خيار التثبيت هذا. ^{[ 36 ] [ 37 ]} كما توجد بعض الأقراص التي لا تُطبِّق بشكل صحيح امتداد مسح ذاكرة التخزين المؤقت للكتابة اللازم لعمل الحواجز، مما يُسبب تحذيرًا مشابهًا. ^{[ 38 ]} في هذه الحالات، حيث لا تكون الحواجز مدعومة أو عملية، يُمكن ضمان ترتيب كتابة موثوق عن طريق إيقاف تشغيل ذاكرة التخزين المؤقت للكتابة في القرص واستخدام data=journalخيار التثبيت. ^{[ 32 ]} قد يكون إيقاف تشغيل ذاكرة التخزين المؤقت للكتابة في القرص ضروريًا حتى عند توفر الحواجز.

تتوقع تطبيقات مثل قواعد البيانات استدعاء الدالة fsync() لتفريغ عمليات الكتابة المعلقة على القرص، ولا يقوم نظام الحماية دائمًا بمسح ذاكرة التخزين المؤقت للكتابة على القرص استجابةً لهذا الاستدعاء. ^{[ 39 ]} كما توجد مشكلة محتملة في نظام الحماية تتعلق بمعالجة الأخطاء أثناء الأحداث، مثل تعطل القرص. ^{[ 40 ]} ومن المعروف أيضًا أن بعض تقنيات المحاكاة الافتراضية لا تُعيد توجيه أوامر fsync أو flush بشكل صحيح إلى الأجهزة الأساسية (الملفات، وحدات التخزين، القرص) من نظام التشغيل الضيف. ^{[ 41 ]} وبالمثل، تُنفذ بعض الأقراص الصلبة أو وحدات التحكم عملية مسح ذاكرة التخزين المؤقت بشكل غير صحيح أو لا تُنفذها على الإطلاق، ومع ذلك تُعلن عن دعمها، ولا تُرجع أي خطأ عند استخدامها. ^{[ 42 ]} هناك العديد من الطرق للتعامل مع fsync وذاكرة التخزين المؤقت للكتابة بشكل غير صحيح، لذا من الأسلم افتراض أن مسح ذاكرة التخزين المؤقت لا يعمل ما لم يتم اختباره بشكل صريح، بغض النظر عن مدى موثوقية المكونات الفردية.

يخزن نظام الملفات Ext3 التواريخ بتوقيت يونكس باستخدام أربعة بايتات في رأس الملف. لا توفر 32 بت نطاقًا كافيًا لمواصلة معالجة الملفات بعد 18 يناير 2038 - مشكلة عام 2038. ^{[ 43 ]}