فایل‌سیستم نسخه‌دار Tines برای sandboxهای یک‌بارمصرف
خلاصهٔ کامل‌تر
تو محصول 3B شرکت Tines، کد هر step از یه workflow تو یه sandbox لینوکسی تازه اجرا میشه و بعد دور ریخته میشه. ولی مشتری‌ها جایی برای نگه داشتن state لازم داشتن، مثلاً clone کردن ریپو، دیتابیس SQLite از لیدهای Salesforce یا ذخیرهٔ webhookها تو DuckDB. نویسنده (Shayon) توضیح می‌ده که برای همین به هر step یه فایل‌سیستم نسخه‌دار دادن که اجرای sandbox و تغییرات فایل‌هاش مثل یه تراکنش دیتابیس رفتار می‌کنه: یا همه‌ش ثبت میشه یا هیچی.
خواسته‌هاشون مشخص بود: باید یه فایل‌سیستم POSIX واقعی باشه چون Git و SQLite و pip روی mmap و fsync و rename حساب می‌کنن. هیچی نباید روی ماشین اجراکننده بمونه. یه نوشتن ۱۲۸ کیلوبایتی باید معمولاً تو ۲ تا ۴ میلی‌ثانیه ماندگار بشه. بدون S3 هم کار کنه چون 3B نسخهٔ self-hosted داره. و تا جای ممکن ساده بمونه.
step با یه خط VOLUME تو Dockerfile یه volume تعریف می‌کنه که تو مسیر /storage/ mount میشه. sandbox روی gVisor هست (یعنی لایه‌ای که همهٔ system callها رو رهگیری می‌کنه) و عملیات فایل به Nest می‌رسه، یه gofer اختصاصی که بیرون sandbox نشسته. Nest موقع باز کردن فایل اون رو تو یه فایل موقت تو حافظه کپی می‌کنه و یه file descriptor واقعی به sandbox می‌ده، پس خوندن و نوشتن با سرعت حافظه انجام میشه. fsync داخل step فقط کپی محلی رو flush می‌کنه و اگه step کرش کنه یا با کد ۱ خارج بشه، تغییراتش دور ریخته میشه.
هر volume یه سری snapshot تغییرناپذیره به‌علاوهٔ یه pointer که می‌گه کدوم فعلیه. step موفق یه snapshot جدید با copy-on-write می‌سازه، یعنی فقط بخش‌های تغییرکردهٔ درخت دوباره نوشته می‌شن. انتشار یه compare-and-swap روی pointer هست. اگه دو step هم‌زمان نوشته باشن، تغییرات فایل‌های متفاوت روی هم اعمال می‌شن ولی تغییر روی یه فایل مشترک با conflict شکست می‌خوره. fork هم فقط یه pointer دوم به همون snapshot هست، پس volume چند گیگابایتی به سرعت یه volume خالی fork میشه. merge بین branchها هم عمداً پشتیبانی نمی‌شه.
زیر Nest موتور ذخیره‌سازی Spongeblob هست که با Rust نوشته شده و هر دیسک فقط یه پروسهٔ مالک داره. نوشتن‌ها به ته یه فایل بزرگ به اسم pack اضافه می‌شن و با group commit یه fsync مشترک دارن. index یه LSM tree الهام‌گرفته از RocksDB و WiscKey هست. packها بعد از ۳۰ ثانیه یا پر شدن مهر و موم می‌شن و اگه S3 باشه آپلود می‌شن تا داده‌ی سرد از دیسک خالی بشه. تو production خوندن حدود یه میلی‌ثانیه و نوشتن کمی زیر دو میلی‌ثانیه طول می‌کشه. به گفتهٔ نویسنده، نوشتن مستقیم روی S3 هم به‌خاطر تأخیر چند ده میلی‌ثانیه‌ای و هم هزینه کنار گذاشته شد.
نقطه‌ضعف فعلی اینه که ته لاگ روی یه دیسک EBS هست و از دست رفتن خود volume ممکنه تا حدود یه دقیقه نوشتن اخیر رو از بین ببره. برای v2 دارن بین نوشتن ته لاگ روی S3 Express One Zone (حدود ۷ تا ۱۰ میلی‌ثانیه برای هر commit) و ساختن یه لاگ مبتنی بر quorum تصمیم می‌گیرن.
نکات کلیدی:
- هدف تأخیر نوشتن ۱۲۸ کیلوبایتی ۲ تا ۴ میلی‌ثانیه‌ست و تو production نوشتن کمی زیر ۲ میلی‌ثانیه طول می‌کشه
- فایل‌سیستم با gofer اختصاصی Nest روی gVisor ساخته شده، نه FUSE
- هر step موفق یه snapshot جدید می‌سازه و step ناموفق هیچ تغییری ثبت نمی‌کنه
- fork فقط یه pointer جدیده و merge بین branchها پشتیبانی نمی‌شه
- Spongeblob با Rust نوشته شده، index اون LSM tree هست و packها بعد از ۳۰ ثانیه sealed می‌شن
- برای v2 بین S3 Express One Zone و لاگ quorum-based تصمیم‌گیری می‌کنن
