Modal تسرّع bun install في بيئات VM المعزولة 12 مرة باستبدال virtio-fs بقرص كتلي

إذا كنتم تبنون بيئات معزولة (sandboxes) للوكلاء، فأنتم تعرفون أن الإقلاع السريع لا يعني بالضرورة عملًا سريعًا. فالوكيل يثبّت الاعتماديات، ويشغّل grep على المستودع، ويغيّر صلاحيات آلاف الملفات. وكل ذلك يعتمد على نظام الملفات. وقد روى مهندسو Modal كيف تعثروا في ذلك عند إطلاق VM Sandboxes وماذا فعلوا.

إقلاع سريع وعمل بطيء

لدى Modal منذ مدة نظام ImageFS، وهو نظام ملفات موزّع بتحميل كسول للحاويات. فهو يجلب مسبقًا فهرس البيانات الوصفية فقط، ويستخرج محتوى الملفات عند الطلب من ذاكرة تخزين مؤقت متعددة المستويات: الذاكرة، وشبكات CDN الإقليمية، والتخزين العالمي. لذلك تقلع الحاويات في أقل من ثانية. وتوضع فوقه طبقة OverlayFS للكتابة.

ومع الأجهزة الافتراضية المنطق نفسه: للجهاز الافتراضي نواة ضيف (kernel) خاصة به، ولا وصول مباشرًا إلى ImageFS على المضيف. والجسر القياسي هو virtio-fs، حيث يطبّق الخدمة virtiofsd على المضيف طلبات الضيف على مجلد مشترك. وُجّه هذا المجلد إلى ImageFS، فبقي الإقلاع كما كان.

لكن أثناء العمل انهار كل شيء. فقد استغرق chown التعاقبي أكثر من دقيقة بدل أربع ثوانٍ. وتباطأ bun install وpnpm install إلى نحو ثلاثة أضعاف، وكان التراجع الأكبر في ripgrep. وفي اختبار مصغّر من 100 ألف استدعاء استغرق chown مدة 9,87 ثانية مقابل 2,31 ثانية تحت gVisor و1,58 ثانية على ImageFS الخام.

لماذا يتحول chown واحد إلى ثلاث رحلات

أظهر التتبع الأمر الأهم. فعملية chown واحدة في نواة الضيف تتحول إلى ثلاثة طلبات إلى المضيف: getxattr للتحقق من capabilities، وgetattr لبتّات setuid، وsetattr لتغيير المالك نفسه. وتنفذ الخدمة ست استدعاءات نظام، وكل منها يصل إلى ImageFS. المحصلة نحو 99 ميكروثانية للعملية الواحدة، علمًا بأن virtiofsd كان مضبوطًا أصلًا على أقصى تخزين مؤقت.

جذر المشكلة في البنية. فـ virtio-fs نظام ملفات مشترك: وفي كل مرة يجب الرجوع في البيانات الوصفية إلى المرجع الواقع على الجانب الآخر من حدود الجهاز الافتراضي. مع أن المضيف لا يحتاج أصلًا إلى محتوى نظام الملفات الجذر للجهاز الافتراضي.

نتحدث بلغة الكتل

اقترح المهندسون إبقاء نظام الملفات بالكامل داخل الضيف، وإعطاء المضيف جهازًا كتليًا فقط عبر virtio-blk. فالقرص لا يعرف ما هو الملف: إنه يخزّن قطع البيانات ويعيدها. أما ext4 داخل الضيف فتتحقق بنفسها من الصلاحيات، وتمسح البتّات، وتسجل التغيير في السجل (journal). ولا يصل ذلك إلى المضيف إلا لاحقًا، دفعة واحدة، كل بضع ثوانٍ. وتكلّف عملية chown الواحدة نحو 2,1 ميكروثانية بدل 99.

والصعوبة أن mkfs.ext4 يتطلب أن تكون الصورة كاملة حاضرة، وهذا يقتل التحميل الكسول. لذلك يكتب الفريق بنفسه سجلات inode الخاصة بـ ext4 اعتمادًا على البيانات الوصفية للصورة، ويترك الباقي متناثرًا (sparse). ويحوّل خدمة ImageFS-blk الطلبات الكتلية إلى قراءة نطاقات من ملفات ImageFS، ويضع الكتل المكتوبة في ملف sparse ويعلّمها في خريطة بتّات. إنه نظير OverlayFS لكن على مستوى الكتل. وبهذا يزول ألم قديم: إذ يعمل النسخ عند الكتابة على كتلة واحدة لا على الملف كله. ففي أسوأ الحالات كان OverlayFS ينسخ غيغابايتات من أجل بضعة بايتات.

النتائج والمقايضة

الأرقام (virtio-fs وImageFS وImageFS-blk):

• bun install: 12,5 ثانية، 3,1 ثانية، 1,07 ثانية؛
• ripgrep على مستودع Linux مع ذاكرة دافئة: 6,03 ثانية، 3,77 ثانية، 0,18 ثانية؛
• SQLite speedtest1: 543 ثانية، 290 ثانية، 43 ثانية؛
• pgbench للقراءة فقط: 98 ألف، 137 ألف، 230 ألف TPS؛
• pgbench للقراءة والكتابة: 8,3 ألف، 11,9 ألف، 18,8 ألف TPS.

تفوق ImageFS-blk حتى على ImageFS الأصلي: فالبيانات الوصفية لم تعد تمر عبر FUSE. وبقي الإقلاع البارد ضمن حدود الثانية.

وللنهج ثمن. فالمضيف لم يعد يرى الملفات داخل الجهاز الافتراضي: إنه يعرف الكتل فقط، وتُحسب اللقطات (snapshots) بحسب مجموعة الكتل المتغيرة. وعلى ذاكرة باردة يستغرق ripgrep على المستودع 8,53 ثانية مع ImageFS-blk مقابل 4,47 ثانية مع ImageFS العادي. هنا يخسر النهج الكتلي. وكل الأرقام حصلت عليها Modal نفسها على أجهزتها، ولا يوجد تحقق مستقل.

ماذا تفعلون بهذا

إذا كنتم تبنون أجهزة افتراضية مصغّرة (micro-VM) للوكلاء أو CI، فلا تعتمدوا virtio-fs كنظام ملفات جذر افتراضي. ففي بيئة معزولة منفردة لا يقرأ فيها المضيف ملفات الضيف، يصبح نظام الملفات المشترك ضريبة زائدة على كل عملية بيانات وصفية. اختبروا لا الإقلاع البارد فقط، بل سيناريوهكم الفعلي: تثبيت الحزم، والبحث في الشيفرة، وchown، وقاعدة البيانات. وهناك بالذات يظهر فارق بعشرة أضعاف.