Daniel Botha का तर्क है कि इन्फ़्रास्ट्रक्चर बनाते समय लक्ष्य एक सरल, भरोसेमंद समाधान होना चाहिए, जैसे 1 डॉलर का स्पेगेटी का पैकेट, न कि कोई चतुर समाधान। जब Sprites पर काम शुरू हुआ, तो टीम को कोई उपयुक्त फ़ाइल सिस्टम बाज़ार में नहीं मिला, इसलिए उसने अपना खुद बनाया। वह डिज़ाइन चतुर था, और इसी वजह से टीम को वह बाद में पसंद नहीं आया। यह पोस्ट उसकी जगह लेने वाले Sprites Block Device (SBD) का परिचय देती है।
Sprite की डिस्क की जड़ अब भी ऑब्जेक्ट स्टोरेज है, न कि उस सर्वर की NVMe ड्राइव जिस पर वह चलता है। इसी से Sprite सो सकता है, किसी दूसरे सर्वर पर जाग सकता है और फिर भी अपनी फ़ाइलें पा सकता है। चूँकि ऑब्जेक्ट स्टोर किसी ऑब्जेक्ट के एक हिस्से को नहीं बदल सकते, इसलिए कोई परत इन-प्लेस फ़ाइल संपादनों को पूरे ऑब्जेक्ट के लिखने में बदलती है। लॉन्च के समय यह भूमिका JuiceFS के एक भारी संशोधित संस्करण ने निभाई थी, जिसका बैकएंड एक फिर से लिखा गया SQLite मेटाडेटा स्टोर था, जिसे Litestream से टिकाऊ रखा गया था। यह भीतर ext4 वाली एक 100 GB की डिस्क इमेज संग्रहीत करता था, और चेकपॉइंट तेज़ थे क्योंकि वे ज़्यादातर केवल मेटाडेटा को इधर-उधर करते थे।
उपयोग बढ़ने के साथ दरारें दिखने लगीं। यह सिस्टम दो अलग-अलग टिकाऊ डेटाबेस पर निर्भर था, एक चंक मेटाडेटा के लिए और एक चेकपॉइंट के लिए, और एक सही हो सकता था जबकि बाकी गलत। JuiceFS को writeback मोड में चलाने का मतलब था कि क्रैश होने पर मेटाडेटा ऐसे चंक्स की ओर इशारा कर सकता था जो कभी अपलोड ही नहीं हुए। ऊपर की ext4 परत तब checksum में विफल होकर केवल-पठन मोड में चली जाती थी, और वही चंक्स साझा करने वाले चेकपॉइंट इस नुकसान की मरम्मत नहीं कर सकते थे।
SBD इस डिज़ाइन की जगह एक अधिक पारंपरिक तरीका लाता है, जिसका लक्ष्य वही सरल व्यवहार है पर बेहतर विश्वसनीयता के साथ।
स्रोत: Hacker News · HeadlinesBriefing द्वारा सारांशित