تم نشر المقابلة الثانية مع إدوارد شيشكين، مطور نظام الملفات Reiser4.
للبدء، يرجى تذكير القراء أين ومن تعمل.
أعمل كمهندس تخزين رئيسي في شركة Huawei Technologies، مركز الأبحاث الألماني. في قسم المحاكاة الافتراضية أتعامل مع الجوانب المختلفة لتخزين البيانات. أنشطتي لا تتعلق بنظام تشغيل معين.
هل أنت ملتزم حاليًا بفرع النواة الرئيسي؟
نادرًا جدًا، وفقط إذا طلب صاحب العمل ذلك. كانت آخر مرة منذ حوالي ثلاث سنوات، حيث قمت بإرسال تصحيحات لزيادة إنتاجية التخزين المشترك على المضيفين باستخدام بروتوكول 9p (اسم آخر لهذا العمل هو VirtFS). يجب ملاحظة ملاحظة مهمة هنا: على الرغم من أنني أعمل مع Linux لفترة طويلة، إلا أنني لم أكن معجبًا به أبدًا، أي أنني "أتنفس بشكل متساوٍ"، كما هو الحال مع كل شيء آخر. وعلى وجه الخصوص، إذا لاحظت وجود خلل، فيمكنني الإشارة إليه مرة واحدة على الأكثر. ومن ثم يمكنك متابعة شخص ما وإقناعه - وهذا لن يحدث.
أتذكر آخر مرة، قبل عشر سنوات، كنت تنتقد بشدة أسلوب تطوير النواة. من وجهة نظرك (أو ربما وجهة نظر الشركة)، هل تغير أي شيء، هل أصبح المجتمع أكثر استجابة أم لا؟ إذا لم يكن الأمر كذلك، في رأيك من يقع اللوم؟
لم أر قط أي تغييرات نحو الأفضل. المشكلة الرئيسية للمجتمع هي استبدال العلم بالتقنيات السياسية، والعلاقات الشخصية، ورأي الأغلبية، والشعبوية، ونصائح "الأصوات الداخلية"، والتسويات الفاسدة، وأي شيء آخر غير العلم. علوم الكمبيوتر، بغض النظر عما قد يقوله المرء، هي أولاً وقبل كل شيء علم دقيق. وإذا بدأ شخص ما في الإعلان عن قيمته الخاصة لـ 2x2، والتي تختلف عن 4، تحت راية "طريقة Linux"، أو تحت راية أخرى، فمن غير المرجح أن يجلب هذا أي شيء سوى الضرر.
ترجع جميع المشاكل في المقام الأول إلى عدم كفاءة ونقص تعليم أولئك الذين يتخذون القرارات. إذا كان المدير غير كفء، فهو غير قادر على اتخاذ قرار موضوعي ومناسب. إذا كان أيضا غير مثقف، فلن يتمكن من العثور على أخصائي مختص يقدم له النصيحة الصحيحة. مع احتمال كبير، سيقع الاختيار على المحتال الذي يقول "أشياء تبدو صحيحة". تتطور البيئة الفاسدة دائمًا حول قادة منفردين غير أكفاء. ثم إن التاريخ لا يعرف استثناءات في هذا الصدد، والمجتمع أوضح تأكيد على ذلك.
كيف تقيم التقدم في تطوير Btrfs؟ هل تخلص هذا FS من أمراض الطفولة؟ كيف يمكنك وضعه لنفسك - كخدمة مالية "للمنزل" أو لاستخدام الشركات أيضًا؟
لم أتخلص منه. كل ما ذكرته قبل 11 عامًا لا يزال ذا صلة اليوم. إحدى مشاكل Btrfs التي تجعلها غير مناسبة للاحتياجات الجادة هي مشكلة المساحة الحرة. أنا لا أتحدث حتى عن حقيقة أنه يُطلب من المستخدم الركض إلى المتجر للحصول على قرص جديد في المواقف التي يُظهر فيها أي FS آخر مساحة كبيرة على القسم. إن عدم القدرة على إكمال العملية على وحدة تخزين منطقية بسبب نقص المساحة الحرة ليس هو الأسوأ أيضًا. أسوأ ما في الأمر هو أن المستخدم الذي لا يتمتع بأي امتيازات يمكنه دائمًا تجاوز أي حصص للقرص وحرمان الجميع من المساحة الحرة في وقت قصير إلى حد ما.
يبدو الأمر هكذا (تم اختباره لـ Linux kernel 5.12). يتم تشغيل البرنامج النصي على نظام تم تثبيته حديثًا، والذي يقوم في حلقة متكررة بإنشاء ملفات بأسماء معينة في الدليل الرئيسي، ويكتب البيانات إليها بإزاحات معينة، ثم يحذف هذه الملفات. بعد دقيقة من تشغيل هذا البرنامج النصي، لا يحدث شيء غير عادي. بعد خمس دقائق، يزداد جزء المساحة المشغولة على القسم قليلاً. وبعد ساعتين إلى ثلاث ساعات يصل إلى 50% (بقيمة أولية 15%). وبعد خمس أو ست ساعات من العمل، يتعطل البرنامج النصي بسبب الخطأ "لا توجد مساحة خالية على القسم". بعد ذلك، لم تعد قادرًا على كتابة حتى ملف 4K على القسم الخاص بك.
يحدث موقف مثير للاهتمام: انتهى بك الأمر إلى عدم كتابة أي شيء على القسم، واختفت كل المساحة الحرة (حوالي 85٪) في مكان ما. سيكشف تحليل القسم الذي يتعرض لمثل هذا الهجوم عن العديد من العقد الشجرية التي تحتوي على عنصر واحد فقط (كائن مجهز بمفتاح)، بحجم عدة بايتات. أي أن المحتوى الذي كان يشغل سابقًا 15٪ من مساحة القرص قد تم "تلطيخه" بالتساوي على القسم بأكمله بحيث لا يوجد مكان لكتابة ملف جديد، لأن مفتاحه أكبر من جميع الملفات الموجودة، والملف المجاني نفدت الكتل الموجودة على القسم.
علاوة على ذلك، كل هذا يحدث بالفعل في تكوين Btrfs الأساسي (بدون أي لقطات أو مجلدات فرعية، وما إلى ذلك)، ولا يهم كيف تقرر تخزين نصوص الملفات في FS (مثل "أجزاء" في شجرة، أو كنطاقات من الكتل غير المنسقة) - ستكون النتيجة النهائية هي نفسها.
لن تتمكن من إخضاع أنظمة الملفات الأولية الأخرى لمثل هذا الهجوم (بغض النظر عما يخبرونك به). لقد شرحت سبب المشكلة منذ وقت طويل: هذا تحريف كامل لمفهوم B-tree في Btrfs، مما يجعله من الممكن أن يتدهور بشكل عفوي أو متعمد. على وجه الخصوص، في ظل أحمال معينة، سوف "ينهار" نظام الملفات الخاص بك بشكل مستمر أثناء التشغيل من تلقاء نفسه، دون مساعدة خارجية. من الواضح أن جميع أنواع عمليات الخلفية "الملحة" لن تنقذ الموقف إلا على أجهزة سطح المكتب الفردية.
على الخوادم الجماعية، سيتمكن المهاجم دائمًا من "التقدم" عليهم. لن يتمكن مسؤول النظام حتى من تحديد من قام بالتخويف عليه بالضبط. أسرع طريقة لإصلاح هذه المشكلة في Btrfs هي استعادة بنية شجرة B العادية، أي. إعادة تصميم تنسيق القرص وإعادة كتابة أجزاء كبيرة من كود Btrfs. سيستغرق ذلك من 8 إلى 10 سنوات، بما في ذلك تصحيح الأخطاء، بشرط أن يتبع المطورون بدقة المقالات الأصلية حول الخوارزميات وهياكل البيانات ذات الصلة، ولم يلعبوا لعبة "الهاتف المكسور"، كما هو معتاد (ومشجع) في "Linux" طريق".
نحتاج هنا أيضًا إلى إضافة الوقت اللازم للمطورين لفهم كل هذا. هذا هو المكان الذي يصبح فيه الأمر أكثر صعوبة. على أية حال، عشر سنوات لم تكن كافية لكي يفهموا. حسنًا، حتى ذلك الحين لا يمكنك أن تأمل في حدوث معجزة. لن يحدث ذلك في شكل خيار تركيب "لم نكن نعرفه أنا وأنت"، أو في شكل تصحيح "مجرد مسألة عمل" للتحضير. ولكل "إصلاح" متسرع سأقدم سيناريو جديدا للانحطاط. تعتبر أشجار B أحد موضوعاتي المفضلة، ويجب أن أقول إن هذه الهياكل لا تتسامح مع الحريات مع نفسها!
كيف أقوم بوضع Btrfs بنفسي؟ كشيء لا يمكن تسميته على الإطلاق بنظام الملفات، ناهيك عن استخدامه. لأنه، بحكم التعريف، FS هو نظام فرعي لنظام التشغيل مسؤول عن الإدارة الفعالة لمورد "مساحة القرص"، وهو ما لا نراه في حالة Btrfs. حسنًا، تخيل أنك أتيت إلى المتجر لشراء ساعة حتى لا تتأخر عن العمل، وبدلاً من الساعة باعوا لك شواية كهربائية بمؤقت لمدة أقصاها 30 دقيقة. لذا فإن الوضع مع Btrfs أسوأ.
من خلال البحث في القوائم البريدية، غالبًا ما أجد عبارة مفادها أن إدارة مساحة القرص بشكل فعال لم تعد ذات صلة بسبب رخص محركات الأقراص. هذا محض هراء. بدون مدير فعال لمساحة القرص، سيصبح نظام التشغيل ضعيفًا وغير قابل للاستخدام. بغض النظر عن سعة الأقراص الموجودة على جهازك.
أود أن أطلب التعليق على وقف دعم Btrfs في RHEL.
لا يوجد شيء خاص للتعليق عليه هنا، كل شيء واضح للغاية. لقد حصلوا عليها أيضًا على أنها "معاينة تقنية". لذلك، لم أقم بهذه "المعاينة" ذاتها. لا تدع هذه التسمية معلقة إلى الأبد! لكنهم لا يستطيعون إطلاق منتج ذو تصميم ثانوي معيب بدعم كامل. RHEL هي مؤسسة، أي علاقات السلع والمال الموصوفة. لا تستطيع Red Hat التنمر على المستخدمين كما يفعلون في القائمة البريدية لـ Btrfs. فقط تخيل الموقف: العميل الذي دفع أمواله التي حصل عليها بشق الأنفس مقابل القرص ودفعك أيضًا مقابل الدعم، يريد أن يفهم أين ذهبت مساحة القرص الخاصة به بعد أن لم يكتب أي شيء. فماذا ستجيبه على هذا؟
إضافي. يشمل عملاء Red Hat البنوك والبورصات الكبيرة المعروفة. تخيل ماذا سيحدث إذا تعرضوا لهجمات DoS بناءً على الثغرة الأمنية المذكورة في Btrfs. من برأيك المسؤول عن هذا؟ لأولئك الذين هم على وشك الإشارة بإصبعهم إلى سطر ترخيص GPL، حيث يُكتب أن المؤلف غير مسؤول عن أي شيء، سأقول على الفور: "أخفِه بعيدًا!" سوف يجيب ريد هات، وبطريقة لن تبدو كافية! لكنني أعلم أن شركة Red Hat لا تواجه هذا النوع من المشاكل، نظرًا لفريقها القوي بشكل خاص من مهندسي ضمان الجودة الذين أتيحت لي الفرصة للعمل معهم بشكل وثيق في وقتي.
لماذا تستمر بعض الشركات في دعم Btrfs في منتجات مؤسساتها؟
يرجى ملاحظة أن البادئة "مؤسسة" في اسم المنتج لا تعني الكثير. المؤسسة هي مقياس للمسؤولية المضمنة في العلاقة التعاقدية مع العميل. أعرف مؤسسة واحدة فقط تعتمد على GNU/Linux - RHEL. كل شيء آخر، من وجهة نظري، يتم تقديمه فقط كمشروع، ولكنه ليس كذلك. وأخيرًا، إذا كان هناك طلب على شيء ما، فسيكون هناك دائمًا عرض (في حالتنا، هذا هو "الدعم" المذكور). هناك طلب على كل شيء على الاطلاق، بما في ذلك. والبرمجيات غير صالحة للاستعمال. أما كيفية تشكيل هذا الطلب ومن يغذيه فهو موضوع آخر.
لذا، لن أقفز إلى أي استنتاجات بعد أن ترددت شائعات عن قيام فيسبوك بنشر Btrfs على خوادمه. علاوة على ذلك، أوصي بعناية بالحفاظ على سرية عناوين تلك الخوادم للأسباب المذكورة أعلاه.
لماذا تم بذل الكثير من الجهد لتنظيف كود XFS مؤخرًا؟ بعد كل شيء، هذا في البداية نظام ملفات تابع لجهة خارجية، وكان ext4 مستقرًا لفترة طويلة ويتمتع بالاستمرارية من الإصدارات السابقة المستقرة بنفس القدر. ما هو اهتمام Red Hat بـ XFS؟ هل من المنطقي تطوير نظامين للملفات متشابهين في الغرض - ext4 وXFS؟
لا أتذكر ما الدافع وراء ذلك. من المحتمل جدًا أن تكون المبادرة قد جاءت من عملاء Red Hat. أتذكر أنه تم إجراء بحث من هذا النوع: في بعض أنظمة الملفات من المنبع، تم إنشاء عدد هائل من الكائنات على محركات الأقراص المتطورة للجيل الجديد. وفقا للنتائج، تصرف XFS بشكل أفضل من ext4. لذلك بدأوا في الترويج لها باعتبارها الأكثر واعدة. على أية حال، لن أبحث عن أي شيء مثير هنا.
بالنسبة لي، يبدو الأمر كما لو أنهم استبدلوا المخرز بالصابون. ليس هناك فائدة من تطوير ext4 وXFS. سواء بالتوازي وأي منهم للاختيار من بينها. لن يأتي شيء جيد من هذا. على الرغم من أنه في الطبيعة غالبا ما تكون هناك مواقف عندما يكون هناك الكثير من إمكانات النمو، ولكن لا يوجد مجال للنمو. في هذه الحالة، تنشأ العديد من النموات الجديدة القبيحة والغريبة، والتي يشير إليها الجميع بإصبعهم ("أوه، انظر، ما لن تراه في هذه الحياة!").
هل تعتقد أن مسألة انتهاك الطبقة قد تمت تسويتها (بالمعنى السلبي) مع ظهور وظائف التشفير في ext4 وF2FS (ناهيك عن RAID في Btrfs)؟
بشكل عام، فإن إدخال أي مستويات واتخاذ القرار بشأن عدم مخالفتها عادة ما يكون مسألة سياسة، ولا أتعهد بالتعليق على أي شيء هنا. الجوانب الموضوعية لانتهاك الطبقة ليست ذات أهمية كبيرة لأي شخص، ولكن يمكننا النظر في بعضها باستخدام مثال الانتهاك "من الأعلى"، أي التنفيذ في FS للوظيفة الموجودة بالفعل على طبقة الكتلة. مثل هذا "الانتهاك" له ما يبرره باستثناءات نادرة فقط. وفي كل حالة من هذا القبيل، يجب عليك أولاً إثبات شيئين: أن هناك حاجة إليه فعلاً، وأن تصميم النظام لن يتضرر من القيام بذلك.
على سبيل المثال، النسخ المتطابق، والذي كان تقليديًا نشاطًا لطبقة الكتلة، من المنطقي تنفيذه على مستوى نظام الملفات. لأسباب مختلفة. على سبيل المثال، يحدث تلف البيانات "الصامت" (تعفن البت) على محركات الأقراص. يحدث هذا عندما يعمل الجهاز بشكل صحيح، لكن بيانات الكتلة تتضرر بشكل غير متوقع تحت تأثير جاما الكم الصلب المنبعث من كوازار بعيد، وما إلى ذلك. أسوأ شيء هو إذا تبين أن هذه الكتلة هي كتلة نظام FS (كتلة فائقة، كتلة الصورة النقطية، عقدة شجرة التخزين، وما إلى ذلك)، لأن هذا سيؤدي بالتأكيد إلى ذعر النواة.
يرجى ملاحظة أن المرايا التي توفرها طبقة الكتلة (ما يسمى RAID 1) لن تنقذك من هذه المشكلة. حسنًا، حقًا: هل يجب على شخص ما التحقق من المجموع الاختباري وقراءة النسخة المتماثلة في حالة الفشل؟ بالإضافة إلى ذلك، من المنطقي أن لا تعكس كل شيء فحسب، بل البيانات الوصفية فقط. يمكن تخزين بعض البيانات المهمة (على سبيل المثال، الملفات القابلة للتنفيذ للتطبيقات الهامة) كبيانات تعريفية. وفي هذه الحالة، يحصلون على نفس ضمانات السلامة. من المنطقي أن نعهد بحماية البيانات المتبقية إلى أنظمة فرعية أخرى (وربما حتى تطبيقات المستخدم) - لقد قدمنا جميع الشروط اللازمة لذلك.
مثل هذه المرايا "الاقتصادية" لها الحق في الوجود، ولا يمكن تنظيمها بشكل فعال إلا على مستوى نظام الملفات. وبخلاف ذلك، فإن انتهاك الطبقات يؤدي إلى ازدحام النظام الفرعي بكود مكرر من أجل بعض الفوائد المجهرية. ومن الأمثلة الصارخة على ذلك تطبيق RAID-5 باستخدام FS. مثل هذه الحلول (RAID / LVM الخاصة في نظام الملفات) تقتل الأخير من الناحية المعمارية. وتجدر الإشارة هنا أيضًا إلى أن انتهاك الطبقات يتم "بثه" بواسطة أنواع مختلفة من المحتالين في مجال التسويق. في حالة عدم وجود أي أفكار، تتم إضافة الوظائف التي تم تنفيذها منذ فترة طويلة على المستويات المجاورة إلى الأنظمة الفرعية، ويتم تقديمها كميزة جديدة مفيدة للغاية ويتم دفعها بنشاط.
تم اتهام Reiser4 بانتهاك المستويات "من الأسفل". استنادًا إلى حقيقة أن نظام الملفات ليس متجانسًا، مثل جميع الأنظمة الأخرى، ولكنه معياري، تم افتراض افتراض غير مدعوم بأنه يفعل ما يجب أن يفعله المستوى الأعلى (VFS).
هل من الممكن الحديث عن وفاة ReiserFS v3.6 وJFS على سبيل المثال؟ في الآونة الأخيرة لم يتلقوا أي اهتمام تقريبًا في القلب. هل عفا عليها الزمن؟
نحن هنا بحاجة إلى تحديد ما يعنيه موت منتج برمجي. فمن ناحية، يتم استخدامها بنجاح (وهذا ما خلقت من أجله في نهاية المطاف)، مما يعني أنها تعيش. من ناحية أخرى، لا أستطيع التحدث باسم JFS (لا أعرف الكثير)، ولكن ReiserFS (الإصدار 3) من الصعب جدًا التكيف مع الاتجاهات الجديدة (تم اختباره عمليًا). هذا يعني أن المطورين في المستقبل لن ينتبهوا إليها، بل إلى تلك التي يسهل التكيف معها. من هذا الجانب يتبين أنه للأسف ميت من الناحية المعمارية. لن أتلاعب بمفهوم "عفا عليه الزمن أخلاقيا" على الإطلاق. إنه ينطبق بشكل جيد، على سبيل المثال، على خزانة الملابس، ولكن ليس على منتجات البرمجيات. هناك مفهوم الدونية والتفوق في شيء ما. أستطيع أن أقول بكل تأكيد أن ReserFS v3 أصبح الآن أدنى من Reiser4 في كل شيء، ولكنه في بعض أنواع أحمال العمل يتفوق على جميع خدمات الخدمات الأولية الأخرى.
هل تعلم عن تطوير FS Tux3 وHAMMER/HAMMER2 (FS لـ DragonFly BSD)؟
نعم نحن نعلم. في Tux3، كنت مهتمًا ذات مرة بتكنولوجيا اللقطات الخاصة بهم (ما يسمى بـ "مؤشرات الإصدار")، ولكن في Reiser4 سنسير على الأرجح في طريق مختلف. لقد كنت أفكر في دعم اللقطات لفترة طويلة ولم أقرر بعد كيفية تنفيذها لمجلدات Reiser4 البسيطة. والحقيقة هي أن تقنية العداد المرجعي "الكسولة" الجديدة التي اقترحها أوهاد روده تعمل فقط مع أشجار B. ليس لدينا لهم. بالنسبة لهياكل البيانات المستخدمة في Reiesr4، لم يتم تعريف العدادات "الكسولة" - لإدخالها، من الضروري حل بعض المشكلات الخوارزمية، والتي لم يتعامل معها أحد بعد.
بحسب هامر: قرأت مقالاً من المؤلف. غير مهتم. مرة أخرى، أشجار ب. هيكل البيانات هذا قديم بشكل ميؤوس منه. لقد تخلينا عنها في القرن الماضي.
كيف يمكنك تقييم الطلب المتزايد على الخدمات الثابتة لمجموعة الشبكات مثل CephFS/GlusterFS/etc؟ هل يعني هذا الطلب تحولاً في أولويات المطورين نحو الخدمات الثابتة للشبكة وعدم الاهتمام الكافي بالخدمات المالية المحلية؟
نعم، لقد حدث مثل هذا التحول في الأولويات. لقد توقف تطوير أنظمة الملفات المحلية. للأسف، أصبح الآن من الصعب جدًا القيام بشيء مهم للأحجام المحلية ولا يستطيع الجميع القيام بذلك. لا أحد يريد الاستثمار في تنميتها. هذا يشبه تقريبًا مطالبة منظمة تجارية بتخصيص أموال للبحث الرياضي - دون أي حماس سوف يسألونك عن كيفية جني الأموال من نظرية جديدة. الآن، FS المحلي هو شيء يظهر بطريقة سحرية "خارج الصندوق" و"يجب أن يعمل دائمًا"، وإذا لم يعمل، فإنه يسبب تذمرًا دون معالجة مثل: "نعم، بماذا يفكرون!"
ومن هنا عدم الاهتمام بالخدمات المالية المحلية، على الرغم من أنه لا يزال هناك الكثير من العمل في هذا المجال. ونعم، لقد تحول الجميع إلى التخزين الموزع، والذي تم إنشاؤه على أساس أنظمة الملفات المحلية الموجودة بالفعل. إنه عصري للغاية الآن. عبارة "البيانات الضخمة" تسبب اندفاع الأدرينالين لدى الكثيرين، وربطها بالمؤتمرات وورش العمل والرواتب الكبيرة وما إلى ذلك.
ما مدى معقولية تطبيق نظام ملفات الشبكة في مساحة kernel بدلاً من مساحة المستخدم؟
نهج معقول للغاية لم يتم تنفيذه بعد في أي مكان. بشكل عام، فإن السؤال عن المساحة التي ينبغي تطبيق نظام ملفات الشبكة فيها هو "سيف ذو حدين". حسنًا، دعونا نلقي نظرة على مثال. قام العميل بتسجيل البيانات على جهاز بعيد. لقد سقطوا في ذاكرة التخزين المؤقت لصفحتها على شكل صفحات قذرة. هذه هي مهمة نظام ملفات الشبكة "البوابة الرفيعة" في مساحة النواة. ثم سيطلب منك نظام التشغيل عاجلاً أم آجلاً كتابة تلك الصفحات على القرص لتحريرها. ثم يتم تشغيل وحدة FS الخاصة بشبكة إعادة توجيه الإدخال والإخراج (الإرسال). فهو يحدد جهاز الخادم (عقدة الخادم) الذي ستنتقل إليه هذه الصفحات.
ثم يتولى مكدس الشبكة المسؤولية (وكما نعلم، يتم تنفيذه في مساحة kernel). بعد ذلك، تتلقى عقدة الخادم تلك الحزمة التي تحتوي على البيانات أو البيانات الوصفية وتوجه وحدة التخزين الخلفية (أي FS المحلي الذي يعمل في مساحة kernel) لتسجيل كل هذه الأشياء. لذلك، قمنا بتقليص السؤال إلى أين يجب أن تعمل وحدتا "الإرسال" و"الاستقبال". إذا تم تشغيل أي من هذه الوحدات في مساحة المستخدم، فسيؤدي ذلك حتمًا إلى تبديل السياق (بسبب الحاجة إلى استخدام خدمات kernel). يعتمد عدد هذه المفاتيح على تفاصيل التنفيذ.
إذا كان هناك العديد من هذه المفاتيح، فسوف ينخفض إنتاجية التخزين (أداء الإدخال/الإخراج). إذا كانت مساحة التخزين الخلفية لديك مكونة من أقراص بطيئة، فلن تلاحظ انخفاضًا كبيرًا. ولكن إذا كان لديك أقراص سريعة (SSD، NVRAM، وما إلى ذلك)، فإن تبديل السياق يصبح بالفعل "عنق الزجاجة"، ومن خلال توفير تبديل السياق، يمكن زيادة الأداء بشكل كبير. الطريقة القياسية لتوفير المال هي نقل الوحدات إلى مساحة النواة. على سبيل المثال، وجدنا أن نقل خادم 9p من QEMU إلى النواة الموجودة على الجهاز المضيف يؤدي إلى زيادة ثلاثة أضعاف في أداء VirtFS.
هذه، بالطبع، ليست شبكة FS، ولكنها تعكس تماما جوهر الأشياء. الجانب السلبي لهذا التحسين هو مشكلات قابلية النقل. بالنسبة للبعض، قد يكون هذا الأخير حاسما. على سبيل المثال، لا يحتوي GlusterFS على وحدات نمطية في النواة على الإطلاق. وبفضل هذا، فهو يعمل الآن على العديد من المنصات، بما في ذلك NetBSD.
ما هي المفاهيم التي يمكن أن تستعيرها الخدمات الثابتة المحلية من الشبكات والعكس؟
في الوقت الحاضر، تحتوي FSs على الشبكة، كقاعدة عامة، على وظائف إضافية على FSs المحلية، لذلك لا أفهم تمامًا كيف يمكنك استعارة شيء ما من الأخير. حسنًا، في الواقع، دعونا نفكر في شركة مكونة من 4 موظفين، حيث يقوم كل فرد بعمله الخاص: أحدهم يوزع، والآخر يرسل، والثالث يستلم، والرابع يخزن. والسؤال، ما الذي يمكن للشركة اقتراضه من موظفها الذي يقوم بتخزينه، يبدو غير صحيح إلى حد ما (لقد كان لديها بالفعل ما كان يمكن أن تقترضه منه لفترة طويلة).
لكن الخدمات المالية المحلية لديها الكثير لتتعلمه من الشبكات. أولاً، يجب أن تتعلم منهم كيفية تجميع وحدات التخزين المنطقية على مستوى عالٍ. الآن ما يسمى تقوم أنظمة الملفات المحلية "المتقدمة" بتجميع الأحجام المنطقية حصريًا باستخدام تقنية "الجهاز الظاهري" المستعارة من LVM (نفس انتهاك الطبقات المعدية الذي تم تنفيذه لأول مرة في ZFS). بمعنى آخر، تتم ترجمة العناوين الافتراضية (أرقام الكتل) إلى عناوين حقيقية ثم إرجاعها عند مستوى منخفض (أي بعد أن يصدر نظام الملفات طلب إدخال/إخراج).
يرجى ملاحظة أن إضافة وإزالة الأجهزة إلى وحدات التخزين المنطقية (وليس المرايا) المرتبة على طبقة الكتلة يؤدي إلى مشكلات يصمت عنها موردو هذه "الميزات" بشكل متواضع. أنا أتحدث عن التجزئة على الأجهزة الحقيقية، والتي يمكن أن تصل إلى قيم وحشية، بينما على جهاز افتراضي، كل شيء على ما يرام. ومع ذلك، يهتم عدد قليل من الأشخاص بالأجهزة الافتراضية: الجميع مهتم بما يحدث على أجهزتك الحقيقية. لكن FS المشابه لـ ZFS (وكذلك أي FS بالاشتراك مع LVM) يعمل فقط مع أجهزة القرص الظاهري (تخصيص عناوين القرص الظاهري من بين العناوين المجانية، وإلغاء تجزئة هذه الأجهزة الافتراضية، وما إلى ذلك). وليس لديهم أي فكرة عما يحدث على الأجهزة الحقيقية!
تخيل الآن أن لديك صفر تجزئة على الجهاز الافتراضي (أي أن لديك نطاقًا عملاقًا واحدًا فقط يعيش هناك)، وقمت بإضافة قرص إلى حجمك المنطقي، ثم قم بإزالة قرص عشوائي آخر من حجمك المنطقي ثم أعد التوازن. ومرات عديدة. ليس من الصعب أن تتخيل أنه على الجهاز الافتراضي ستظل تعيش نفس القدر من الحياة، ولكن على الأجهزة الحقيقية لن ترى أي شيء جيد.
أسوأ شيء هو أنك غير قادر حتى على تصحيح هذا الوضع! الشيء الوحيد الذي يمكنك فعله هنا هو أن تطلب من نظام الملفات إلغاء تجزئة الجهاز الظاهري. لكنها ستخبرك أن كل شيء على ما يرام هناك - هناك حد واحد فقط، والتجزئة صفر، ولا يمكن أن يكون أفضل! لذا، فإن وحدات التخزين المنطقية المرتبة على مستوى الكتلة ليست مخصصة للإضافة/الإزالة المتكررة للأجهزة. بطريقة جيدة، ما عليك سوى تجميع وحدة تخزين منطقية على مستوى الكتلة مرة واحدة، وإعطائها لنظام الملفات، ثم عدم القيام بأي شيء آخر بها.
بالإضافة إلى ذلك، فإن الجمع بين الأنظمة الفرعية FS+LVM المستقلة لا يسمح بمراعاة الطبيعة المختلفة لمحركات الأقراص التي يتم تجميع وحدات التخزين المنطقية منها. في الواقع، لنفترض أنك قمت بتجميع وحدة تخزين منطقية من محركات الأقراص الثابتة وأجهزة الحالة الصلبة. ولكن بعد ذلك سيتطلب الأول إلغاء التجزئة، والأخير لن يفعل ذلك. بالنسبة للأخيرة، تحتاج إلى إصدار طلبات تجاهل، ولكن بالنسبة للأولى، لا، وما إلى ذلك. ومع ذلك، في هذا المزيج من الصعب جدًا إظهار مثل هذه الانتقائية.
لاحظ أنه بعد إنشاء LVM الخاص بك على نظام الملفات، فإن الوضع لا يتحسن كثيرًا. علاوة على ذلك، من خلال القيام بذلك، فإنك تضع حدًا لاحتمال تحسينه في المستقبل. وهذا أمر سيء للغاية. يمكن أن تعيش أنواع مختلفة من محركات الأقراص على نفس الجهاز. وإذا كان نظام الملفات لا يميز بينهما فمن سيفعل؟
مشكلة أخرى تكمن في انتظار ما يسمى. أنظمة الملفات "الكتابة في أي مكان" (يتضمن ذلك أيضًا Reiser4، إذا قمت بتحديد نموذج المعاملات المناسب أثناء التحميل). يجب أن توفر أنظمة الملفات هذه أدوات إلغاء التجزئة غير المسبوقة في قوتها. ومدير الحجم المنخفض المستوى لا يساعد هنا، ولكنه يعيق الطريق فقط. الحقيقة هي أنه مع مثل هذا المدير، سيقوم FS الخاص بك بتخزين خريطة الكتل المجانية لجهاز واحد فقط - جهاز افتراضي. وفقا لذلك، يمكنك فقط إلغاء تجزئة الجهاز الظاهري. وهذا يعني أن أداة إلغاء التجزئة الخاصة بك ستعمل لفترة طويلة جدًا على مساحة واحدة ضخمة من العناوين الافتراضية.
وإذا كان لديك الكثير من المستخدمين الذين يقومون بالكتابة العشوائية، فسيتم تقليل التأثير المفيد لأداة إلغاء التجزئة هذه إلى الصفر. سيبدأ نظامك في التباطؤ حتمًا، ولن يتعين عليك سوى طي يديك أمام التشخيص المخيب للآمال "التصميم المكسور". العديد من أدوات إلغاء التجزئة التي تعمل على نفس مساحة العنوان سوف تتداخل مع بعضها البعض فقط. سيكون الأمر مختلفًا تمامًا إذا كنت تحتفظ بخريطة الكتل المجانية الخاصة بك لكل جهاز حقيقي. سيؤدي هذا إلى موازاة عملية إلغاء التجزئة بشكل فعال.
ولكن هذا لا يمكن القيام به إلا إذا كان لديك مدير حجم منطقي عالي المستوى. أنظمة الملفات المحلية مع هؤلاء المديرين لم تكن موجودة من قبل (على الأقل لا أعرف عنها). فقط أنظمة ملفات الشبكة (على سبيل المثال GlusterFS) لديها مثل هؤلاء المديرين. مثال آخر مهم للغاية هو الأداة المساعدة للتحقق من سلامة وحدة التخزين (fsck). إذا قمت بتخزين خريطة مستقلة خاصة بك للكتل الحرة لكل مجلد فرعي، فيمكن موازنة إجراء التحقق من الحجم المنطقي بشكل فعال. وبعبارة أخرى، فإن الكميات المنطقية التي يديرها مديرون رفيعو المستوى تتوسع بشكل أفضل.
بالإضافة إلى ذلك، مع مديري الحجم ذوي المستوى المنخفض، لن تتمكن من تنظيم لقطات كاملة. باستخدام أنظمة الملفات المشابهة لـ LVM وZFS، يمكنك فقط التقاط لقطات محلية، وليس لقطات عامة. تسمح لك اللقطات المحلية باستعادة عمليات الملفات العادية فقط على الفور. ولن يتراجع أحد عن العمليات ذات الأحجام المنطقية (إضافة/إزالة الأجهزة). دعونا ننظر إلى هذا مع مثال. في وقت ما، عندما يكون لديك وحدة تخزين منطقية لجهازين A وB تحتوي على 100 ملف، فإنك تأخذ لقطة للنظام S ثم تقوم بإنشاء مائة ملف أخرى.
بعد ذلك، يمكنك إضافة الجهاز C إلى وحدة التخزين الخاصة بك، وأخيرًا استرجاع نظامك إلى لقطة S. سؤال: كم عدد الملفات والأجهزة التي يحتوي عليها المجلد المنطقي الخاص بك بعد العودة إلى S؟ سيكون هناك 100 ملف، كما قد تكون خمنت، ولكن سيكون هناك 3 أجهزة - هذه هي نفس الأجهزة A وB وC، على الرغم من أنه في وقت إنشاء اللقطة لم يكن هناك سوى جهازين في النظام (A وB) ). لم يتم التراجع عن عملية إضافة الجهاز C، وإذا قمت الآن بإزالة الجهاز C من الكمبيوتر، فسوف يؤدي ذلك إلى إتلاف بياناتك، لذا قبل الحذف، ستحتاج أولاً إلى إجراء عملية مكلفة لإزالة الجهاز من وحدة التخزين المنطقية لإعادة التوازن، والتي سوف ينثر جميع البيانات من الجهاز C إلى الجهازين A وB. ولكن إذا كان FS الخاص بك يدعم اللقطات العامة، فلن تكون إعادة التوازن هذه مطلوبة، وبعد العودة الفورية إلى S، يمكنك إزالة الجهاز C بأمان من الكمبيوتر.
لذا، تعد اللقطات العامة جيدة لأنها تسمح لك بتجنب الإزالة (الإضافة) المكلفة لجهاز من وحدة تخزين منطقية (إلى وحدة تخزين منطقية) بكمية كبيرة من البيانات (بالطبع، إذا كنت تتذكر "لقطة" لنظامك في الوقت المناسب). اسمحوا لي أن أذكرك أن إنشاء اللقطات وإعادة نظام الملفات إليها هي عمليات فورية. قد يطرح السؤال: كيف يمكن التراجع على الفور عن عملية على وحدة تخزين منطقية استغرقت ثلاثة أيام؟ لكن هذا ممكن! بشرط أن يكون نظام الملفات الخاص بك مصممًا بشكل صحيح. خطرت لي فكرة مثل هذه "اللقطات ثلاثية الأبعاد" منذ ثلاث سنوات، وفي العام الماضي حصلت على براءة اختراع لهذه التقنية.
الشيء التالي الذي يجب أن تتعلمه الخدمات الثابتة المحلية من الشبكات هو تخزين البيانات التعريفية على أجهزة منفصلة بنفس الطريقة التي تخزنها الخدمات الثابتة المحلية على أجهزة منفصلة (ما يسمى بخوادم البيانات التعريفية). هناك تطبيقات تعمل بشكل أساسي مع البيانات التعريفية، ويمكن تسريع هذه التطبيقات بشكل كبير عن طريق وضع البيانات التعريفية على أجهزة تخزين باهظة الثمن وعالية الأداء. مع مجموعة FS+LVM، لن تتمكن من إظهار مثل هذه الانتقائية: LVM لا يعرف ما هو موجود في الكتلة التي مررتها إليه (البيانات الموجودة هناك أو البيانات الوصفية).
لن تحصل على فائدة كبيرة من تنفيذ LVM منخفض المستوى الخاص بك في FS مقارنةً بمجموعة FS+LVM، ولكن ما يمكنك فعله جيدًا هو إحداث فوضى في FS بحيث يصبح من المستحيل لاحقًا العمل مع الكود الخاص به. إن ZFS وBtrfs، اللتين اندفعتا نحو الأجهزة الافتراضية، كلها أمثلة واضحة على الكيفية التي يؤدي بها انتهاك الطبقات إلى قتل النظام من الناحية المعمارية. فلماذا أفعل كل هذا إذن؟ علاوة على ذلك، ليست هناك حاجة لتثبيت LVM منخفض المستوى الخاص بك في نظام الملفات. بدلاً من ذلك، تحتاج إلى تجميع الأجهزة في وحدات تخزين منطقية على مستوى عالٍ، كما تفعل بعض أنظمة ملفات الشبكة مع أجهزة مختلفة (عقد تخزين). صحيح أنهم يفعلون ذلك بشكل مثير للاشمئزاز بسبب استخدام خوارزميات سيئة.
من أمثلة الخوارزميات الرهيبة تمامًا مترجم DHT في نظام الملفات GlusterFS وما يسمى بخريطة CRUSH في نظام الملفات Ceph. لم تكن أي من الخوارزميات التي رأيتها ترضيني من حيث البساطة وقابلية التوسع الجيدة. لذلك كان علي أن أتذكر الجبر وأخترع كل شيء بنفسي. في عام 2015، أثناء تجربة الحزم على وظائف التجزئة، توصلت إلى شيء يناسبني وحصلت على براءة اختراع. الآن أستطيع أن أقول إن محاولة وضع كل هذا موضع التنفيذ كانت ناجحة. لا أرى أي مشاكل مع قابلية التوسع في النهج الجديد.
نعم، سيتطلب كل مجلد فرعي بنية منفصلة مثل الكتلة الفائقة في الذاكرة. هل هذا مخيف جدا؟ بشكل عام، لا أعرف من سيقوم "بغلي المحيط" وإنشاء مجلدات منطقية من مئات الآلاف أو أكثر من الأجهزة على جهاز محلي واحد. إذا كان أي شخص يستطيع أن يشرح لي هذا، سأكون ممتنا للغاية. في هذه الأثناء، بالنسبة لي هذا هراء تسويقي.
كيف أثرت التغييرات في النظام الفرعي لجهاز كتلة kernel (على سبيل المثال، مظهر blk-mq) على متطلبات تنفيذ FS؟
ولم يكن لهم أي تأثير. لا أعرف ما الذي سيحدث على طبقة الكتلة مما يجعل من الضروري تصميم FS جديد. واجهة التفاعل لهذه الأنظمة الفرعية سيئة للغاية. من جانب برنامج التشغيل، يجب أن يتأثر FS فقط بمظهر أنواع جديدة من محركات الأقراص، والتي سيتم ضبط طبقة الكتلة عليها أولاً، ثم FS (بالنسبة إلى Reiser4، سيعني هذا ظهور مكونات إضافية جديدة).
هل ظهور أنواع جديدة من الوسائط (على سبيل المثال، SMR، أو انتشار محركات أقراص الحالة الثابتة في كل مكان) يعني تحديات جديدة بشكل أساسي لتصميم نظام الملفات؟
نعم. وهذه حوافز طبيعية لتطوير FS. يمكن أن تكون التحديات مختلفة وغير متوقعة على الإطلاق. على سبيل المثال، سمعت عن محركات أقراص تعتمد فيها سرعة عملية الإدخال/الإخراج بشكل كبير على حجم جزء من البيانات وإزاحته. في Linux، حيث لا يمكن أن يتجاوز حجم كتلة FS حجم الصفحة، لن يُظهر محرك الأقراص هذا إمكاناته الكاملة افتراضيًا. ومع ذلك، إذا تم تصميم نظام الملفات الخاص بك بشكل صحيح، فهناك فرصة لتحقيق المزيد منه.
كم عدد الأشخاص الذين يعملون حاليًا باستخدام كود Reiser4 غيرك؟
أقل مما أريد، لكنني لا أعاني من نقص حاد في الموارد أيضًا. أنا أكثر من راضٍ عن وتيرة تطوير Reiser4. لن أقوم "بقيادة الخيول" - فهذه ليست المنطقة الصحيحة. هنا، "إذا كنت تقود السيارة بهدوء أكبر، فسوف تستمر في السير!" يعد نظام الملفات الحديث هو النظام الفرعي الأكثر تعقيدًا للنواة، حيث يمكن لقرارات التصميم الخاطئة أن تؤدي إلى التراجع عن السنوات اللاحقة من العمل البشري.
من خلال تقديم متطوعين لتنفيذ شيء ما، أضمن دائمًا أن الجهود ستؤدي بالتأكيد إلى النتيجة الصحيحة، والتي قد تكون مطلوبة لاحتياجات جدية. كما تفهم، لا يمكن أن يكون هناك العديد من هذه الضمانات في وقت واحد. في الوقت نفسه، لا أستطيع تحمل "الشخصيات" التي تروج بلا خجل لـ "ميزات" البرامج غير القابلة للاستخدام بشكل واضح، وتخدع مئات المستخدمين والمطورين، وفي نفس الوقت تجلس وتبتسم في قمة النواة.
هل أعربت أي شركة عن استعدادها لدعم تطوير Reiser4؟
نعم، كانت هناك مثل هذه المقترحات، بما في ذلك. ومن بائع كبير. ولكن لهذا كان علي أن أنتقل إلى بلد آخر. لسوء الحظ، لم يعد عمري 30 عامًا، ولا يمكنني الانفصال والمغادرة بهذه الطريقة عند صافرة البداية.
ما هي الميزات المفقودة حاليا من Reiser4؟
لا توجد وظيفة "تغيير الحجم" للمجلدات البسيطة، مماثلة لتلك الموجودة في ReiserFS(v3). بالإضافة إلى ذلك، لن تؤذي عمليات الملفات باستخدام علامة DIRECT_IO. بعد ذلك، أود أن أكون قادرًا على فصل المجلد إلى "مجلدات فرعية دلالية"، والتي ليس لها حجم ثابت، والتي يمكن تركيبها كمجلدات مستقلة. هذه المشاكل مفيدة للمبتدئين الذين يرغبون في تجربة "الشيء الحقيقي".
وأخيرًا، أرغب في الحصول على وحدات تخزين منطقية للشبكة ذات تنفيذ وإدارة بسيطة (الخوارزميات الحديثة تسمح بذلك بالفعل). ولكن ما لن يمتلكه Reiser4 أبدًا هو RAID-Z، والدعك، وذاكرة التخزين المؤقت للمساحة الحرة، ومتغيرات 128 بت وغيرها من الهراء التسويقي الذي نشأ على خلفية نقص الأفكار بين مطوري بعض أنظمة الملفات.
هل يمكن تنفيذ كل ما قد يكون مطلوبًا بواسطة المكونات الإضافية؟
إذا كنا نتحدث فقط من حيث الواجهات والمكونات الإضافية (الوحدات) التي تنفذها، فليس كل شيء. ولكن إذا قمت أيضًا بتقديم علاقات على هذه الواجهات، فمن بين أشياء أخرى، سيكون لديك مفاهيم تعدد الأشكال الأعلى، والتي يمكنك التعامل معها بالفعل. تخيل أنك قمت افتراضيًا بتجميد نظام وقت تشغيل موجه للكائنات، وقمت بتغيير قيمة مؤشر التعليمات للإشارة إلى مكون إضافي آخر يقوم بتنفيذ نفس واجهة X، ثم قمت بإلغاء تجميد النظام بحيث يستمر في التنفيذ.
إذا لم يلاحظ المستخدم النهائي مثل هذا "الاستبدال"، فإننا نقول أن النظام لديه تعدد الأشكال ذو الترتيب الصفري في الواجهة X (أو أن النظام غير متجانس في الواجهة X، وهو نفس الشيء). إذا لم يكن لديك الآن مجموعة من الواجهات فحسب، بل لديك أيضًا علاقات عليها (الرسم البياني للواجهة)، فيمكنك إدخال تعدد الأشكال ذات الترتيب الأعلى، والذي سيميز عدم تجانس النظام الموجود بالفعل في "جوار" أي واجهة. لقد قدمت مثل هذا التصنيف منذ وقت طويل، ولكن لسوء الحظ، لم يحدث ذلك أبدا.
لذلك، بمساعدة المكونات الإضافية وتعدد الأشكال الأعلى، يمكنك وصف أي ميزة معروفة، بالإضافة إلى "التنبؤ" بتلك التي لم يتم ذكرها من قبل. لم أتمكن من إثبات ذلك بشكل صارم، لكنني أيضًا لا أعرف مثالًا مضادًا حتى الآن. بشكل عام، ذكرني هذا السؤال بـ "برنامج إرلانجن" لفيليكس كلاين. في وقت من الأوقات حاول تمثيل الهندسة كلها كفرع من الجبر (على وجه التحديد، نظرية المجموعة).
الآن إلى السؤال الرئيسي - كيف تسير الأمور مع ترقية Reiser4 إلى النواة الرئيسية؟ هل كانت هناك أي منشورات حول بنية نظام الملفات هذا تحدثت عنها في المقابلة الأخيرة؟ ما مدى أهمية هذا السؤال من وجهة نظرك؟
بشكل عام، كنا نطالب بإدراجنا في الفرع الرئيسي منذ ثلاث سنوات. بقي تعليق رايزر الأخير في الموضوع العام حيث تم تقديم طلب السحب دون إجابة. لذلك كل الأسئلة الأخرى ليست لنا. أنا شخصياً لا أفهم سبب حاجتنا إلى "الاندماج" في نظام تشغيل معين. في نظام التشغيل Linux، لم يتقارب الضوء مثل الإسفين. لذلك، يوجد مستودع منفصل حيث سيكون هناك العديد من المنافذ الفرعية لأنظمة تشغيل مختلفة. يمكن لأي شخص يحتاج إليه استنساخ المنفذ المقابل والقيام بكل ما تريد به (ضمن الترخيص بالطبع). حسنًا، إذا كان شخص ما لا يحتاج إليها، فهذه ليست مشكلتي. في هذه المرحلة، أقترح النظر في مسألة "الترقية إلى نواة Linux الرئيسية" كما تمت تسويتها.
تعد المنشورات المتعلقة بهندسة FS ذات صلة، ولكن حتى الآن لم أجد سوى الوقت لنتائجي الجديدة، والتي أعتبرها أولوية أعلى. شيء آخر هو أنني عالم رياضيات، وفي الرياضيات أي منشور هو ملخص للنظريات وبرهاناتها. إن نشر أي شيء هناك دون دليل هو علامة على سوء الذوق. إذا قمت بإثبات أو دحض أي بيان حول بنية FS، فستكون النتيجة مثل هذه الأكوام التي سيكون من الصعب للغاية تجاوزها. من يحتاجها؟ ربما يكون هذا هو السبب وراء استمرار بقاء كل شيء في شكله القديم - كود المصدر والتعليقات عليه.
ما الجديد في Reiser4 خلال السنوات القليلة الماضية؟
لقد تحقق الاستقرار الذي طال انتظاره أخيراً. وكان آخر ما ظهر هو الخطأ الذي أدى إلى وجود أدلة "غير قابلة للحذف". كانت الصعوبة هي أنها ظهرت فقط على خلفية تصادمات تجزئة الأسماء ومع موقع معين لسجلات الدليل في عقدة شجرة. ومع ذلك، ما زلت لا أستطيع أن أوصي بـ Reiser4 للإنتاج: لهذا تحتاج إلى القيام ببعض الأعمال مع التفاعل النشط مع مسؤولي نظام الإنتاج.
لقد نجحنا أخيرًا في تنفيذ فكرتنا القديمة - نماذج المعاملات المختلفة. في السابق، كان Reiser4 يشغل نموذجًا واحدًا فقط من طراز Macdonald-Reiser مضمنًا. هذا خلق مشاكل التصميم. على وجه الخصوص، اللقطات غير ممكنة في نموذج المعاملات هذا - سيتم إتلافها بواسطة مكون ذري يسمى "OVERWRITE SET". يدعم Reiser4 حاليًا ثلاثة نماذج للمعاملات. في إحداها (الكتابة في أي مكان)، تتضمن مجموعة الكتابة فوق المكون الذري صفحات النظام فقط (صور الصور النقطية للقرص، وما إلى ذلك)، والتي لا يمكن "تصويرها" (مشكلة الدجاجة والبيضة).
لذلك يمكن الآن تحقيق الصور بأفضل طريقة ممكنة. في نموذج معاملات آخر، تنتقل كافة الصفحات المعدلة إلى مجموعة الكتابة الفوقية (OVERWRITE SET) فقط (أي أنها عبارة عن يوميات خالصة بشكل أساسي). هذا النموذج مخصص لأولئك الذين اشتكوا من التجزئة السريعة لأقسام Reiser4. الآن في هذا النموذج، لن يتم تجزئة القسم الخاص بك بشكل أسرع من ReiserFS (الإصدار 3). جميع النماذج الثلاثة الموجودة، مع بعض التحفظات، تضمن ذرية العمليات، لكن النماذج التي تحتوي على فقدان الذرية وتحافظ فقط على سلامة القسم يمكن أن تكون مفيدة أيضًا. يمكن أن تكون مثل هذه النماذج مفيدة لجميع أنواع التطبيقات (قواعد البيانات، وما إلى ذلك)، والتي قامت بالفعل ببعض هذه الوظائف. من السهل جدًا إضافة هذه النماذج إلى Reiser4، لكنني لم أفعل ذلك، لأنه لم يطلب مني أحد ذلك، وأنا شخصيًا لا أحتاج إليه.
ظهرت مجاميع اختبارية للبيانات الوصفية وقمت مؤخرًا باستكمالها بمرايا "اقتصادية" (مادة لا تزال غير مستقرة). إذا فشل المجموع الاختباري لأي كتلة، فسيقوم Reiser4 على الفور بقراءة الكتلة المقابلة من جهاز النسخة المتماثلة. لاحظ أن ZFS وBtrfs لا يستطيعان القيام بذلك: التصميم لا يسمح بذلك. هناك يجب عليك تشغيل عملية مسح خلفية خاصة تسمى "فرك" والانتظار حتى تصل إلى الكتلة التي بها مشكلة. ويطلق المبرمجون اسم "العكازات" على مثل هذه الأحداث مجازيًا.
وأخيرًا، ظهرت وحدات تخزين منطقية غير متجانسة، تقدم كل ما لا يمكن أن توفره ZFS وBtrfs وطبقة الكتل بالإضافة إلى مجموعات FS+LVM من حيث المبدأ - القياس المتوازي، ومخصص عنوان القرص O(1)، وترحيل البيانات الشفاف بين المجلدات الفرعية. يحتوي الأخير أيضًا على واجهة مستخدم. يمكنك الآن بسهولة نقل أهم البيانات إلى محرك الأقراص عالي الأداء على وحدة التخزين الخاصة بك.
بالإضافة إلى ذلك، من الممكن مسح أي صفحات قذرة بشكل عاجل إلى محرك الأقراص هذا، وبالتالي تسريع التطبيقات التي تستدعي fsync(2) بشكل كبير. ألاحظ أن وظيفة طبقة الكتلة، التي تسمى bcache، لا توفر حرية العمل هذه على الإطلاق. تعتمد المجلدات المنطقية الجديدة على خوارزمياتي (هناك براءات اختراع مقابلة). البرنامج مستقر تمامًا بالفعل، ومن الممكن تجربته وقياس الأداء وما إلى ذلك. الإزعاج الوحيد هو أنك تحتاج حاليًا إلى تحديث تكوين وحدة التخزين يدويًا وتخزينه في مكان ما.
لقد تمكنت حتى الآن من تنفيذ أفكاري بنسبة 10 بالمائة، إلا أنني نجحت في ما اعتبرته أصعب شيء - وهو ربط وحدات التخزين المنطقية بإجراء فلاشي ينفذ جميع الإجراءات المؤجلة في reiser4. كل هذا لا يزال في فرع "format41" التجريبي.
هل يجتاز Reiser4 اختبارات xfstests؟
على الأقل هذا ما حدث بالنسبة لي عندما كنت أقوم بإعداد الإصدار الأخير.
هل من الممكن من حيث المبدأ جعل Reiser4 شبكة (مجموعة) FS باستخدام المكونات الإضافية؟
إنه ممكن، بل وضروري! إذا قمت بإنشاء ملف شبكة يعتمد على نظام ملفات محلي مصمم بشكل صحيح، فستكون النتيجة مثيرة للإعجاب للغاية! في FSs الحديثة للشبكة، لست راضيًا عن وجود مستوى تخزين خلفي، والذي يتم تنفيذه باستخدام أي FS محلي. إن وجود هذا المستوى غير مبرر على الإطلاق. يجب أن تتفاعل FS الشبكة مباشرة مع طبقة الكتلة، ولا تطلب من FS المحلي إنشاء أي ملفات خدمة أخرى!
بشكل عام، تقسيم أنظمة الملفات إلى نظام محلي وشبكة هو من الشر. لقد نشأت من النقص في الخوارزميات التي تم استخدامها قبل ثلاثين عامًا، والتي لم يتم اقتراح أي شيء بدلاً منها حتى الآن. وهذا أيضًا هو سبب ظهور كتلة من مكونات البرامج غير الضرورية (الخدمات المختلفة، وما إلى ذلك). بطريقة جيدة، يجب أن يكون هناك FS واحد فقط في شكل وحدة kernel ومجموعة من أدوات المستخدم المساعدة المثبتة على كل جهاز - عقدة نظام المجموعة. هذا FS محلي وشبكة. ولا شيء أكثر!
إذا لم ينجح أي شيء مع Reiser4 على Linux، أود أن أقدم FS لـ FreeBSD (اقتباس من مقابلة سابقة: "...FreeBSD... له جذور أكاديمية... وهذا يعني أنه بدرجة عالية من الاحتمالية نحن سوف تجد لغة مشتركة مع المطورين")؟
لذلك، كما اكتشفنا للتو، كل شيء يعمل بشكل مثالي مع Linux: هناك منفذ Reiser4 منفصل يعمل به في شكل فرع رئيسي لمستودعنا. لم أنس فري بي إس دي! يعرض! أنا على استعداد للعمل بشكل وثيق مع أولئك الذين يعرفون الدواخل الداخلية لـ FreeBSD جيدًا. بالمناسبة: ما يعجبني حقًا في مجتمعهم هو أن القرارات هناك يتم اتخاذها من قبل مجلس محدث من الخبراء المستقلين، وهو ما لا علاقة له بخداع الحكومة لشخص دائم واحد.
كيف تقيم مجتمع مستخدمي Linux اليوم؟ هل أصبح أكثر "البوب"؟
ونظرًا لطبيعة عملي، من الصعب جدًا بالنسبة لي تقييم ذلك. يأتي إليّ معظم المستخدمين بتقارير الأخطاء وطلبات إصلاح القسم. المستخدمين كمستخدمين. البعض أكثر ذكاءً، والبعض الآخر أقل. الجميع يعاملون بنفس الطريقة. حسنًا، إذا تجاهل المستخدم تعليماتي، فاعذرني: سيتم إدخال أمر التجاهل من جهتي أيضًا.
هل من الممكن التنبؤ بتطور أنظمة الملفات خلال السنوات الخمس إلى العشر القادمة؟ ما هي برأيك التحديات الرئيسية التي قد يواجهها مطورو الخدمات المالية؟
نعم، ليس من الصعب تقديم مثل هذه التوقعات. لم يكن هناك تطور لأنظمة الملفات في المنبع لفترة طويلة. يتم إنشاء مظهر مثل هذا فقط. واجه مطورو أنظمة الملفات المحلية مشكلات مرتبطة بالتصميم السيئ. يجب أن يتم التحذير هنا. لا أعتبر ما يسمى بـ "التخزين" و"اللعق" ونقل التعليمات البرمجية بمثابة تطوير وتطوير. ولا أصنف سوء التفاهم المسمى “Btrfs” على أنه تطور للأسباب التي سبق أن أوضحتها.
كل تصحيح يجعل مشاكله أسوأ. حسنًا. وهناك دائمًا أنواع مختلفة من "المبشرين" الذين "يعمل كل شيء من أجلهم". في الأساس، هؤلاء هم تلاميذ المدارس والطلاب الذين يتخطون المحاضرات. فقط تخيل: إنه يعمل لصالحه، لكن الأستاذ لا يعمل. ما هذا الاندفاع الأدرينالين! من وجهة نظري، فإن الضرر الأكبر يحدث بسبب "الحرفيين" الذين سارعوا بحماس إلى "تثبيت" الميزات الرائعة لـ Btrfs على جميع أنواع الطبقات مثل systemd وdocker وما إلى ذلك. - وهذا يشبه بالفعل النقائل.
دعونا الآن نحاول وضع توقعات لمدة خمس إلى عشر سنوات. لقد قمت بالفعل بإدراج ما سنفعله في Reiser4 بإيجاز. سيكون التحدي الرئيسي الذي يواجه مطوري الخدمات المالية المحليين من المنبع (نعم، لقد أصبح بالفعل) هو عدم القدرة على القيام بعمل لائق مقابل راتب. بدون أي أفكار في مجال تخزين البيانات، سيستمرون في محاولة تصحيح هذه VFS وXFS وext4 المؤسفة. يبدو الوضع مع VFS كوميديًا بشكل خاص على هذه الخلفية، ويذكرنا بالتحديث المحموم لمطعم لا يوجد فيه طهاة، ولا يُتوقع وجود طهاة فيه.
الآن، يقوم كود VFS، دون أي شروط، بقفل عدة صفحات ذاكرة في نفس الوقت ويدعو FS الأساسي للعمل عليها. تم تقديم هذا لتحسين أداء Ext4 في عمليات الحذف، ولكن كما هو سهل الفهم، فإن هذا القفل المتزامن غير متوافق تمامًا مع نماذج المعاملات المتقدمة. أي أنك لن تتمكن ببساطة من إضافة دعم لبعض أنظمة الملفات الذكية في النواة. لا أعرف ما هو الوضع في مناطق أخرى من Linux، ولكن فيما يتعلق بأنظمة الملفات، فمن غير المرجح أن يكون أي تطوير هنا متوافقًا مع السياسة التي يتبعها Torvalds عمليًا (يتم طرد المشاريع الأكاديمية، والمحتالون الذين ليس لدي أي فكرة عما يتم إصداره من اعتمادات ثقة لا نهاية لها). ولذلك، تم تحديد مسار للانحلال البطيء. وبطبيعة الحال، سوف يحاولون بكل قوتهم تصويرها على أنها "تنمية".
علاوة على ذلك، فإن "أوصياء" أنظمة الملفات، الذين يدركون أنه لا يمكنك كسب الكثير من "التخزين" وحده، سيجربون أيديهم في أعمال أكثر ربحية. هذه هي، كقاعدة عامة، أنظمة الملفات الموزعة والمحاكاة الافتراضية. ربما سيقومون بنقل ZFS العصري إلى مكان آخر حيث لم يكن موجودًا بعد. لكنها، مثل كل FS من المنبع، تشبه شجرة رأس السنة الجديدة: إذا كان بإمكانك تعليق بعض الأشياء الصغيرة الأخرى في الأعلى، فلن تتمكن من التعمق أكثر. أعترف أنه من الممكن بناء نظام مؤسسي جاد يعتمد على ZFS، ولكن بما أننا نناقش المستقبل الآن، فلا يمكنني إلا أن أقول للأسف أن ZFS ميؤوس منه في هذا الصدد: مع أجهزتهم الافتراضية، قام الرجال بقطع الأكسجين لأنفسهم وللأجيال القادمة لمزيد من التطوير. ZFS هو شيء من الماضي. وext4 وXFS ليست حتى أول من أمس.
تجدر الإشارة بشكل منفصل إلى المفهوم المثير لـ "نظام ملفات Linux للجيل القادم". هذا مشروع سياسي وتسويقي بالكامل تم إنشاؤه لإتاحة الفرصة، إذا جاز التعبير، "لتثبيت مستقبل أنظمة الملفات" في Linux خلف شخصيات محددة. الحقيقة هي أن Linux كان "للمتعة فقط". لكنها الآن في المقام الأول آلة لكسب المال. إنها مصنوعة على كل ما هو ممكن. على سبيل المثال، من الصعب جدًا إنشاء منتج برمجي جيد، لكن "المطورين" الأذكياء أدركوا منذ فترة طويلة أنه ليست هناك حاجة للتوتر على الإطلاق: يمكنك بنجاح بيع البرامج غير الموجودة التي تم الإعلان عنها والترويج لها على جميع أنواع الجمهور الأحداث - الشيء الرئيسي هو أن شرائح العرض التقديمي يجب أن تحتوي على المزيد من "الميزات".
تعتبر أنظمة الملفات مثالية لهذا، لأنه يمكنك المساومة بأمان لمدة عشر سنوات على النتيجة. حسنًا، إذا اشتكى شخص ما لاحقًا من عدم وجود هذه النتيجة بالذات، فهو ببساطة لا يفهم شيئًا عن أنظمة الملفات! وهذا يذكرنا بالهرم المالي: في الأعلى يوجد المغامرون الذين بدأوا هذه الفوضى، وأولئك القلائل الذين كانوا "محظوظين": لقد "سحبوا الأرباح"، أي. حصلوا على أموال من أجل التطوير، وحصلوا على وظيفة جيدة الأجر كمديرين، و"ظهروا" في المؤتمرات، وما إلى ذلك.
ويأتي بعد ذلك أولئك "غير المحظوظين": فسوف يحسبون الخسائر، ويتعاملون مع عواقب نشر منتج برمجي غير قابل للاستخدام في الإنتاج، "إلخ. هناك الكثير منهم. حسنًا، يوجد في قاعدة الهرم عدد كبير من المطورين الذين يقومون "بنشر" أكواد برمجية عديمة الفائدة. وهم أكبر الخاسرين، لأن الوقت الضائع لا يمكن إرجاعه. هذه الأهرامات مفيدة للغاية لتورفالدس ورفاقه. وكلما كثرت هذه الأهرامات كان ذلك أفضل لهم. لتغذية مثل هذه الأهرامات، يمكن أخذ أي شيء إلى القلب. وبطبيعة الحال، في الأماكن العامة يقولون العكس. لكني لا أحكم بالأقوال بل بالأفعال.
لذا، فإن "مستقبل أنظمة الملفات في Linux" هو برنامج آخر يتم الترويج له بشكل كبير، ولكنه بالكاد قابل للاستخدام. بعد Btrfs، مع احتمال كبير، سيتم أخذ مكان مثل هذا "المستقبل" بواسطة Bcachefs، وهي محاولة أخرى لعبور طبقة كتلة Linux مع نظام الملفات (مثال سيء معدي). وما هو نموذجي: هناك نفس المشاكل الموجودة في Btrfs. لقد شككت في هذا لفترة طويلة، ثم بطريقة ما لم أتمكن من المقاومة ونظرت في الكود - هذا صحيح!
استخدم مؤلفو Bcachefs وBtrfs، عند إنشاء FS، مصادر الآخرين بنشاط، ولم يفهموا سوى القليل عنها. الوضع يذكرنا بلعبة الأطفال "الهاتف المكسور". ويمكنني أن أتخيل تقريبًا كيف سيتم تضمين هذا الرمز في النواة. في الواقع، لن يرى أحد "أشعل النار" (سوف يدوس عليها الجميع لاحقًا). بعد العديد من المراوغات حول أسلوب الكود، والاتهامات بارتكاب انتهاكات غير موجودة، وما إلى ذلك، سيتم التوصل إلى نتيجة حول "ولاء" المؤلف، ومدى "تفاعله" مع المطورين الآخرين، ومدى نجاح كل هذا ومن ثم بيعها للشركات.
والنتيجة النهائية لن تهم أحدا. ربما كنت سأهتم بهذا الأمر قبل عشرين عاماً، ولكن الآن أصبحت التساؤلات مطروحة بشكل مختلف: هل من الممكن الترويج لهذا الأمر حتى يتسنى توظيف بعض الأشخاص في غضون الأعوام العشرة المقبلة؟ وللأسف، ليس من المعتاد أن نتساءل عن النتيجة النهائية.
بشكل عام، أنصح بشدة بعدم البدء في إعادة اختراع نظام الملفات الخاص بك من الصفر. لأنه حتى الاستثمارات المالية الكبيرة لن تكون كافية للحصول على شيء تنافسي خلال عشر سنوات. بالطبع، أنا أتحدث عن مشاريع جادة، وليس عن تلك التي تهدف إلى "دفعها" إلى النواة. لذا، فإن الطريقة الأكثر فعالية للتعبير عن نفسك هي الانضمام إلى التطورات الحقيقية، مثلنا. وهذا بالطبع ليس بالأمر السهل - ولكن هذا هو الحال مع أي مشروع رفيع المستوى.
أولا، سوف تحتاج إلى التغلب بشكل مستقل على المشكلة التي سأقدمها. وبعد ذلك، بعد أن اقتنعت بجدية نواياك، سأبدأ في المساعدة. تقليديا، نستخدم فقط التطورات الخاصة بنا. الاستثناءات هي خوارزميات الضغط وبعض وظائف التجزئة. نحن لا نرسل المطورين للسفر لحضور المؤتمرات، ومن ثم لا نجلس ونجمع أفكار الآخرين ("ربما ماذا سيحدث")، كما هو معتاد في معظم الشركات الناشئة.
نحن نطور جميع الخوارزميات بأنفسنا. أنا مهتم حاليًا بالجوانب الجبرية والاندماجية لعلم تخزين البيانات. على وجه الخصوص، الحقول المحدودة، المقاربات، إثبات عدم المساواة. هناك أيضًا عمل للمبرمجين العاديين، لكن يجب أن أحذرك على الفور: يتم تجاهل جميع الاقتراحات الخاصة بـ "النظر إلى FS آخر والقيام بنفس الشيء". التصحيحات التي تهدف إلى التكامل الوثيق مع Linux عبر VFS ستنتقل أيضًا إلى هناك.
لذا، ليس لدينا مجرفة، ولكن لدينا فهم للمكان الذي نحتاج إلى التحرك فيه، ولدينا ثقة في أن هذا الاتجاه هو الاتجاه الصحيح. وهذا الفهم لم يأت على شكل المن من السماء. اسمحوا لي أن أذكركم بأن لدينا 29 عامًا من الخبرة في مجال التطوير، ونظامين للملفات مكتوبين من الصفر. ونفس العدد من الأدوات المساعدة لاستعادة البيانات. وهذا كثير!
المصدر: opennet.ru