يرى Daniel Botha أنه عند بناء البنية التحتية ينبغي أن يكون الهدف حلاً بسيطاً وموثوقاً، مثل كيس معكرونة بدولار واحد، لا حلاً ذكياً. عندما بدأ العمل على Sprites، لم يجد الفريق نظام ملفات مناسباً جاهزاً، فبنى نظامه الخاص. كان ذلك التصميم ذكياً، وهذا تحديداً ما جعلهم يكرهونه لاحقاً. يقدّم هذا المنشور بديله، وهو Sprites Block Device (SBD).
ما زال جذر قرص Sprite هو تخزين الكائنات، لا محرك NVMe الموجود في الخادم الذي يعمل عليه. وهذا ما يسمح لـ Sprite بالدخول في وضع السكون، والاستيقاظ على خادم مختلف، والعثور على ملفاته رغم ذلك. ولأن مخازن الكائنات لا تستطيع تعديل جزء من كائن، فلا بد من طبقة تترجم تعديلات الملفات في مكانها إلى كتابات لكائنات كاملة. عند الإطلاق، كان هذا الدور يقوم به إصدار معدّل بشدة من JuiceFS، مدعوم بمخزن بيانات وصفية SQLite أُعيدت كتابته وحُفظ بشكل دائم عبر Litestream. كان يخزّن صورة قرص واحدة بسعة 100 GB تحتوي على ext4، وكانت نقاط الحفظ سريعة لأنها تنقل البيانات الوصفية في معظمها.
ومع ازدياد الاستخدام ظهرت الشقوق. اعتمد النظام على قاعدتي بيانات منفصلتين تحتفظان بالبيانات بشكل دائم، واحدة لبيانات الأجزاء الوصفية وأخرى لنقاط الحفظ، وكان من الممكن أن تكون إحداهما صحيحة بينما الأخرى خاطئة. وتشغيل JuiceFS في وضع الكتابة المؤجلة يعني أن الانهيار قد يترك بيانات وصفية تشير إلى أجزاء لم تُرفع أبداً. فكانت طبقة ext4 الأعلى تفشل في فحوص المجاميع وتتحول إلى وضع القراءة فقط، ولم تستطع نقاط الحفظ، التي تشارك الأجزاء نفسها، إصلاح الضرر.
يستبدل SBD هذا التصميم بنهج أكثر تقليدية، يهدف إلى السلوك البسيط نفسه مع موثوقية أفضل.
المصدر: Hacker News · لخّصه HeadlinesBriefing