systemd'nin mstack'i tek katmanlı dizinleri yazılabilir bağlar, salt okunur dosyaların üzerine sessizce yazar

mstack ne yapar

Mart ayında yayınlanan systemd 260, overlayfs bağlarını tanımlamanın yeni bir yolunu ekledi. Kullanıcı, uzun bir mount -t overlay -o lowerdir=... komut satırını bir araya getirmek yerine, .mstack son ekli bir dizin oluşturuyor, salt okunur katmanlara işaret eden layer@0, layer@1 vb. adlı symlink'leri bırakıyor, yazılabilir üst katman için bir rw/ alt dizini ekliyor ve systemd-mstack --mount komutunu çağırıyor. dev.to'daki bir uygulama yazısına göre systemd 261 — Haziran'da yayınlandı, yazarın güncel bir Arch Linux imajından test ettiği sürüm 261.3 — mekanizmayı systemd-nspawn --mstack= seçeneğine ve servis düzeyinde RootMStack= yönergesine genişletti. Beyan edilen amaç kullanım kolaylığı: bağ yığınları shell betiği büyüleri yerine paylaşılabilir, incelenebilir dizinlere dönüşüyor.

Yazma surprise'ı

Yazıyı ayakta tutan bulgu sert. Yazar iki dosya içeren bir dizin oluşturdu, bunu mstack ile bağladı, bağ üzerinden tek bir satır yazdı ve o satrın salt okunur olarak işaretlenmiş bir dosyanın üzerine kalıcı olarak yazdığını gördü. Komut 0 ile çıktı; ne hata metni ne de uyarı vardı. Yazının başlığı mekanizmayı açıkça dile getiriyor: mstack tek katmanlı bir dizini varsayılan olarak yazılabilir bağlıyor. Pratik sonuç şu: çoğu insanın overlay'lere taşıdığı zihinsel model — alt katmanlar değişmez, yazmalar ayrı bir üst katmana düşer — burada geçerli değil ve kaynak dosyadaki izinler hiçbir koruma sağlamıyor.

Kafa karıştırıcı ve sessiz hata modları

Test sırasında iki kaba kenar daha ortaya çıktı; yazar bunları Docker içinde çalıştırdı çünkü sandbox'ta PID 1 olarak çalışan systemd yoktu.

Birincisi, mstack düz bir Docker container'ının içinde kafa karıştırıcı biçimde başarısız oluyor. Çekirdek, zaten overlayfs üzerinde bulunan dizinlerin üzerine yeni bir overlayfs bağını istiflemez — ki bu da Docker'ın varsayılan overlay2 sürücüsü altında bir container'ın kök dosya sistemidir. El yazımı mount komutu bu kısıtı düz bir dille bildirir ("filesystem on upper not supported as upperdir"); mstack ise bunun yerine (layerfd)' failed with exit status 1 yazdırıp ardından bir "Invalid argument" şikayetiyle devam ediyor ve gerçek sınır yerine dahili bir fonksiyon adını veriyor. Sınırlama mstack'in suçu değil — yazar tarafından ext ailesinden bir host dizininde doğrulanan geçici çözüm, katmanları tmpfs'e veya bind-mount edilmiş bir host dizinine yerleştirmek.

İkincisi, bazı hatalar hiç çıktı üretmiyor. Kopuk bir layer@ symlink'i, inceleme komutunun 1 ile hiçbir mesaj olmadan çıkmasına yol açıyor; "No such file or directory" hatasını yalnızca --mount yüzeye çıkarıyor ve yalnızca bağlama işleminin aracı hedefi gerçekten açmaya zorlaması sayesinde. Bir .mstack içindeki layer@* ya da rw ile eşleşmeyen bir başıboş dosya veya dizin de aynı şekilde davranıyor: 1 ile çıkış, hiçbir şey yazdırılmıyor. Bu dizinleri betiklerle üreten herkes için, arkasında başıboş bir yapıt bırakan bir şablon, üzerinden hareket edilecek hiçbir şey olmayan çıplak bir hatayla sonuçlanıyor.

Hız, depolama ve bir tuhaflık

Belgelerin sürüm sıralaması iddiası doğrulandı: layer@1'den layer@3'e ve layer@10'dan layer@12'ye adlandırılan katmanlar sözcüksel değil sayısal olarak sıralandı, -- çıktısı üzerinden doğrulandı. tmpfs üzerinde her birinden beşer bağlama zamanlanınca, mstack el yazımı komuttan kabaca bir milisaniye yavaş kaldı (4–5ms'ye karşı 3–4ms) — bu, symlink'leri çözmenin ve seçenek dizgisini oluşturmanın bedeli, ve bu ölçekte gürültü.

Gizli bir kopyalama da yok. Bir katmanın içine yerleştirilen 100MB'lık dosya bağ üzerinden tamamen görünürken, mstack'in oluşturduğu geçici hazırlık dizini 40 bayt ölçüldü — yazarın belirttiği gibi, kendini tanımlayan bir soyutlama tam da içine bir kopyalama adımı kaçırabilecek türden bir şey olduğu için bunu söylemeye değer.

Bir gözlem açıklanmadan kaldı: /proc/self/mountinfo, gerçek bir iki katmanlı yığın için aynı geçici yola işaret eden iki özdeş lowerdir+= girdisi gösterdi. Bağ çalıştı ve her iki katmanın dosyaları da mevcuttu; yazar da nedeni hakkında tahmin yürütmek yerine bilinmiyor demeyi tercih etti.

Neden önemli

mstack, overlay kurulumunu bildirimsel ve incelenebilir bir şeye doğru itiyor ve bu, container ile immutable-root kurulumları için gerçek bir kolaylık. Ama mevcut varsayılanları ve tanılamaları dikkatli bir operatör varsayıyor. Salt okunur işaretlerini sessizce etkisiz bırakan yazma davranışı, kullanıcının kurcalamakta güvende olduğuna inandığı bir yığında kaynak veriyi yok edebilir; mesajsız çıkış kodları betiklenmiş pipeline'ları kırılganlaştırır; ve Docker-öncelikli testçi — çoğu insanın ilk içgüdüsü — bir araç hatası kılığına bürünmüş bir çekirdek sınırlamasına çarpar. Tanılamalar düzelene kadar her mstack bağını yazılabilir olarak ele alın, bağ üzerinden bir yazmanın gerçekte neye dokunacağını doğrulayın ve performans kazancı beklemeyin: özelliğin değeri kullanım kolaylığı, hız değil.