نام (NAME)

containers-storage-composefs - اطلاعات مربوط به composefs و ذخیره‌سازی کانتینرها (containers/storage)

توضیحات (DESCRIPTION)

برای فعال‌سازی اولیه composefs به پیکربندی زیر در containers-storage.conf نیاز است:

[storage.options.overlay]
use_composefs = "true"

این مقدار باید یک "رشته بولی" (string bool) باشد و نمی‌تواند یک بولی بومی TOML باشد.

با این حال در حال حاضر composefs نیازمند تصاویر zstd:chunked است، بنابراین ابتدا باید اطمینان حاصل کنید که zstd:chunked فعال است. برای اطلاعات بیشتر، containers-storage-zstd-chunked را ببینید.

علاوه بر این، تصاویر زیادی در قالب zstd:chunked وجود ندارند. برای پر کردن این شکاف، می‌توان convert_images = true را مشخص کرد که تبدیل پویا را انجام می‌دهد؛ این کار کمی تأخیر به دریافت (pull) تصویر اضافه می‌کند.

با کنار هم قرار دادن این موارد، تنظیمات زیر (علاوه بر پیکربندی بالا) مورد نیاز است:

[storage.options.pull_options]
convert_images = "true"

این مقدار باید یک "رشته بولی" باشد و نمی‌تواند یک بولی بومی TOML باشد.

پیاده‌سازی (IMPLEMENTATION)

همان‌طور که از تنظیم use_composefs = true برمی‌آید، در حال حاضر composefs به عنوان یک "گزینه" برای درایور overlay پیاده‌سازی شده است. برخی از قالب‌های پرونده دست‌نخورده باقی می‌مانند و از درایور overlay به ارث می‌رسند، حتی زمانی که composefs در حال استفاده است. تفاوت‌های اصلی در ادامه برشمرده شده‌اند:

پوشه diff/ برای هر لایه دیگر یک بازگشایی ساده از آرشیو tarball نیست، بلکه تبدیل به یک "پوشه هش شیء" (object hash directory) می‌شود که در آن نام هر پرونده برابر با هش sha256 محتویات آن است. این پوشه diff/ به عنوان فضای ذخیره‌سازی پشتیبان برای composefs-data/composefs.blob که برای هر لایه ایجاد می‌شود عمل می‌کند؛ این پرونده همان "سوپربلاک" composefs است که تمام محتوای غیرپرونده‌های معمولی (یعنی متادیتا) را از tarball در خود نگه می‌دارد.

مانند zstd:chunked، لایه‌های موجود برای یافتن اشیاء منطبق اسکن می‌شوند و در صورت یافتن اشیایی با "sha256 کامل" منطبق، مجدداً استفاده می‌شوند (از طریق hardlink یا reflink بر حسب پیکربندی).

در حال حاضر هیچ پشتیبانی از یکپارچگی اجباری در composefs وجود ندارد؛ تلاشی برای فعال‌سازی fsverity برای پرونده‌های پشتیبان و پرونده composefs انجام می‌شود، اما در صورت عدم پشتیبانی خطا تلقی نمی‌شود. هنوز سازوکار مشخصی برای تأیید خلاصه fsverity مربوط به بلوک composefs پیش از سوار کردن وجود ندارد؛ کار روی این موضوع در جریان است.

جهت سوار کردن یک لایه (یا یک تصویر کامل همراه با تمام وابستگی‌های آن)، هر لایه‌ای که دارای بلاب composefs باشد سوار شده و در پشته "نهایی" overlayfs گنجانده می‌شود. این کار اختیاری است - هر لایه‌ای که در قالب composefs نباشد اما در قالب پیش‌فرض overlay (بازگشایی‌شده) باشد، همان‌گونه که هست مورد استفاده مجدد قرار می‌گیرد.

اشکالات (BUGS)

https://github.com/containers/storage/issues?q=is%3Aissue+is%3Aopen+label%3Aarea%2Fcomposefs

پاورقی‌ها (FOOTNOTES)

پروژه Containers Storage به فراگیر بودن و شمولیت، که از ارزش‌های بنیادین متن‌باز است، متعهد می‌باشد. در این مخزن اصطلاحات انتشار اتصال master و slave استفاده شده است. این ادبیات مسأله‌ساز و تفرقه‌انگیز تلقی می‌شود و باید اصلاح گردد؛ با این حال، این اصطلاحات در حال حاضر در هسته لینوکس مورد استفاده هستند و در حال حاضر باید به همین شکل باقی بمانند. هنگامی که نگهدارندگان هسته لینوکس این کاربرد را اصلاح کنند، Containers Storage نیز بلافاصله از آن پیروی خواهد کرد.