Daniel Botha যুক্তি দেন যে অবকাঠামো তৈরির সময় লক্ষ্য হওয়া উচিত একটি সহজ, নির্ভরযোগ্য সমাধান, যেমন ১ ডলারের স্প্যাগেটির প্যাকেট, চতুর কোনো সমাধান নয়। Sprites-এর কাজ শুরু হলে দলটি বাজারে উপযুক্ত কোনো ফাইলসিস্টেম খুঁজে পায়নি, তাই নিজেরাই একটি তৈরি করে। সেই ডিজাইন ছিল চতুর, আর ঠিক সেই কারণেই পরে তারা এটি অপছন্দ করতে শুরু করে। এই পোস্টে তার প্রতিস্থাপন Sprites Block Device (SBD) তুলে ধরা হয়েছে।
একটি Sprite-এর ডিস্কের মূল এখনও অবজেক্ট স্টোরেজ, যে সার্ভারে সেটি চলে সেখানকার NVMe ড্রাইভ নয়। এর ফলে একটি Sprite ঘুমিয়ে পড়তে পারে, অন্য সার্ভারে জেগে উঠতে পারে এবং তবুও তার ফাইলগুলো খুঁজে পায়। অবজেক্ট স্টোর কোনো অবজেক্টের অংশ পরিবর্তন করতে পারে না, তাই কোনো একটি স্তরকে ইন-প্লেস ফাইল সম্পাদনাকে সম্পূর্ণ অবজেক্ট লেখায় রূপান্তর করতে হয়। লঞ্চের সময় এই ভূমিকা পালন করত JuiceFS-এর একটি ব্যাপকভাবে পরিবর্তিত সংস্করণ, যার ব্যাকএন্ড ছিল একটি পুনর্লিখিত SQLite মেটাডেটা স্টোর, যা Litestream দিয়ে স্থায়ী রাখা হতো। এটি ভেতরে ext4 সহ একটি একক 100 GB ডিস্ক ইমেজ সংরক্ষণ করত, এবং চেকপয়েন্টগুলো দ্রুত ছিল কারণ সেগুলো মূলত শুধু মেটাডেটা সরাত।
ব্যবহার বাড়ার সঙ্গে সঙ্গে ফাটল দেখা দিতে লাগল। সিস্টেমটি দুটি আলাদা স্থায়ী ডেটাবেসের ওপর নির্ভর করত, একটি চাঙ্ক মেটাডেটার জন্য এবং একটি চেকপয়েন্টের জন্য, এবং একটি সঠিক থাকলেও অন্যটি ভুল হতে পারত। JuiceFS-কে writeback মোডে চালানোর অর্থ ছিল, ক্র্যাশ হলে মেটাডেটা এমন চাঙ্কের দিকে নির্দেশ করতে পারত যেগুলো কখনও আপলোড হয়নি। উপরের ext4 স্তর তখন checksum-এ ব্যর্থ হয়ে শুধু-পড়া অবস্থায় চলে যেত, এবং একই চাঙ্ক ভাগ করা চেকপয়েন্টগুলো এই ক্ষতি মেরামত করতে পারত না।
SBD এই ডিজাইনের জায়গায় একটি আরও প্রচলিত পদ্ধতি এনেছে, যার লক্ষ্য একই সহজ আচরণ, তবে আরও উন্নত নির্ভরযোগ্যতা।
উৎস: Hacker News · সারাংশ: HeadlinesBriefing