Herkese merhaba, “Linux'ta sanal dosya sistemleri: neden ihtiyaç duyulur ve nasıl çalışırlar?” yayınımızın ikinci bölümünü sizlerle paylaşıyoruz. İlk bölümü okuyabilirsiniz . Bu yayın serisinin, kursta yeni bir yayının başlamasıyla aynı zamana denk gelecek şekilde zamanlandığını hatırlatalım. , çok yakında başlayacak.
eBPF ve bcc araçlarını kullanarak VFS nasıl izlenir
Çekirdeğin dosyalar üzerinde nasıl çalıştığını anlamanın en kolay yolu sysfs bunu pratikte görmek ve ARM64'ü izlemenin en kolay yolu eBPF'yi kullanmaktır. eBPF (Berkeley Paket Filtresi'nin kısaltması), çalışan bir sanal makineden oluşur. ayrıcalıklı kullanıcıların talep edebileceği (query) komut satırından. Çekirdek kaynakları okuyucuya çekirdeğin neler yapabileceğini anlatır; eBPF araçlarını yüklü bir sistemde çalıştırmak, çekirdeğin gerçekte ne yaptığını gösterir.
Neyse ki eBPF'yi kullanmaya başlamak araçların yardımıyla oldukça kolaydır genel dağıtımdan paketler halinde temin edilebilen ve ayrıntılı olarak belgelendi . Aletler bcc küçük C kodu eklemeleri içeren Python komut dosyalarıdır; bu, her iki dile de aşina olan herkesin bunları kolayca değiştirebileceği anlamına gelir. İÇİNDE bcc/tools 80 Python betiği vardır, bu da büyük olasılıkla bir geliştiricinin veya sistem yöneticisinin sorunu çözmeye uygun bir şey seçebileceği anlamına gelir.
Çalışan bir sistemde VFS'lerin ne işe yaradığına dair en azından yüzeysel bir fikir edinmek için şunu deneyin: vfscount veya vfsstat. Bu, diyelim ki, düzinelerce çağrının olduğunu gösterecek. vfs_open() ve "arkadaşları" kelimenin tam anlamıyla her saniye oluyor.
vfsstat.pybasitçe VFS işlev çağrılarını sayan, C kodu eklerine sahip bir Python betiğidir.
Daha basit bir örnek verelim ve bilgisayara bir USB flash sürücü taktığımızda ve sistem bunu algıladığında ne olacağını görelim.
EBPF'yi kullanarak neler olduğunu görebilirsiniz.
/sysUSB flash sürücü takıldığında. Burada basit ve karmaşık bir örnek gösterilmektedir.
Yukarıda gösterilen örnekte, bcc alet komut çalıştırıldığında bir mesaj yazdırır sysfs_create_files(). Bunu görüyoruz sysfs_create_files() kullanılarak başlatıldı kworker flash sürücünün takılmasına yanıt olarak akış, ancak hangi dosya oluşturuldu? İkinci örnek eBPF'nin gücünü göstermektedir. Burada trace.py Bir çekirdek geri izlemesini (-K seçeneği) ve oluşturulan dosyanın adını yazdırır sysfs_create_files(). Tek deyim ekleme, LLVM'yi çalıştıran Python betiği tarafından sağlanan, kolayca tanınabilen bir biçim dizesi içeren C kodudur. tam zamanında derleyici. Bu satırı derler ve çekirdeğin içindeki sanal makinede çalıştırır. Tam işlevli imza sysfs_create_files () biçim dizesinin parametrelerden birine başvurabilmesi için ikinci komutta çoğaltılması gerekir. Bu C kodu parçasındaki hatalar, C derleyicisinde tanınabilir hatalara neden olur. Örneğin, -l parametresi atlanırsa "BPF metni derlenemedi" ifadesini görürsünüz. C ve Python'a aşina olan geliştiriciler araçları bulacak bcc genişletilmesi ve değiştirilmesi kolaydır.
USB sürücüsü takıldığında, çekirdek geri izlemesi PID 7711'in bir iş parçacığı olduğunu gösterecektir. kworkerdosyayı oluşturan «events» в sysfs. Buna göre, çağrı sysfs_remove_files() sürücüyü kaldırmanın dosyanın silinmesine yol açtığını gösterecek eventsreferans sayımının genel konseptine karşılık gelir. Aynı zamanda görüntüleme sysfs_create_link () eBPF ile USB sürücüyü takarken en az 48 sembolik bağlantının oluşturulduğunu gösterecektir.
Peki olaylar dosyasının amacı nedir? Kullanım arama için , neye sebep olduğunu gösterir disk_add_events ()ve ya "media_change"Veya "eject_request" bir olay dosyasına kaydedilebilir. Burada çekirdek blok katmanı kullanıcı alanına bir "disk"in ortaya çıktığını ve çıkarıldığını bildirir. Bir USB sürücüsü takarak yapılan bu araştırma yönteminin, işlerin tamamen kaynaktan nasıl yürüdüğünü anlamaya çalışmakla karşılaştırıldığında ne kadar bilgilendirici olduğuna dikkat edin.
Salt okunur kök dosya sistemleri gömülü aygıtları etkinleştirir
Elbette kimse fişi prizden çekerek sunucuyu veya bilgisayarını kapatmıyor. Ama neden? Bunun nedeni, fiziksel depolama aygıtlarındaki takılı dosya sistemlerinin yazma işlemlerinin gecikmeli olabilmesi ve durumlarını kaydeden veri yapılarının depolamaya yazma işlemleriyle senkronize edilememesidir. Bu durumda, sistem sahiplerinin yardımcı programı başlatmak için bir sonraki önyüklemeye kadar beklemesi gerekir. fsck filesystem-recovery ve en kötü durumda veri kaybı.
Ancak hepimiz birçok IoT cihazının yanı sıra yönlendiricilerin, termostatların ve arabaların da artık Linux çalıştırdığını biliyoruz. Bu cihazların çoğunda kullanıcı arayüzü çok azdır veya hiç yoktur ve bunları "temiz" şekilde kapatmanın bir yolu yoktur. Kontrol ünitesine giden güç kesildiğinde aküsü bitmiş bir arabayı çalıştırdığınızı hayal edin. sürekli olarak yukarı aşağı zıplamak. Sistem nasıl uzun süre beklemeden açılıyor? fsckmotor nihayet ne zaman çalışmaya başlıyor? Ve cevap basit. Gömülü cihazlar kök dosya sistemini kullanır (kısaltılmış ro-rootfs (salt okunur kök dosya sistemi)).
ro-rootfs özgünlükten daha az belirgin olan birçok fayda sunar. Bir avantajı, kötü amaçlı yazılımın yazamamasıdır. /usr veya /lib, eğer hiçbir Linux işlemi oraya yazamıyorsa. Bir diğeri, destek personelinin saha sistemleriyle nominal olarak aynı olan yerel sistemlere güvenmesi nedeniyle, büyük ölçüde değişmez bir dosya sisteminin uzak cihazların saha desteği için kritik öneme sahip olmasıdır. Belki de en önemli (ama aynı zamanda en sinsi) faydası, ro-rootfs'un geliştiricileri sistemin tasarım aşamasında hangi sistem nesnelerinin değişmez olacağına karar vermeye zorlamasıdır. Ro-rootf'larla çalışmak zor ve sancılı olabilir, çünkü const değişkenleri programlama dillerinde sıklıkla bulunur, ancak faydaları ek yükü kolayca haklı çıkarır.
oluşturma rootfs Salt okunur, gömülü geliştiriciler için ekstra çaba gerektirir ve VFS'nin devreye girdiği yer burasıdır. Linux dosyaların içinde olmasını gerektirir /var yazılabilirdi ve ayrıca gömülü sistemleri çalıştıran birçok popüler uygulama, yapılandırma oluşturmaya çalışacaktır. dot-files в $HOME. Ana dizindeki yapılandırma dosyalarına yönelik bir çözüm genellikle bunları önceden oluşturmak ve içine yerleştirmektir. rootfs. Karşı /var Olası bir yaklaşım, onu ayrı bir yazılabilir bölüme monte etmektir. / salt okunur olarak monte edilmiştir. Bir diğer popüler alternatif ise bağlama veya kaplama montajlarını kullanmaktır.
Bağlanabilir ve istiflenebilir montaj parçaları, bunların konteynerler tarafından kullanımı
Bir komutun yürütülmesi man mount geliştiricilere ve sistem yöneticilerine bir yolda dosya sistemi oluşturma ve daha sonra bunu başka bir yoldaki uygulamalara sunma yeteneği veren, bağlanabilir ve üst üste bindirilebilir montajlar hakkında bilgi edinmenin en iyi yoludur. Gömülü sistemler için bu, dosyaları depolama yeteneği anlamına gelir. /var salt okunur bir flash sürücüde, ancak bir kaplama veya bağlanabilir montaj yolu tmpfs в /var yükleme sırasında uygulamaların oraya not yazmasına (karalama) olanak tanır. Değişiklikleri bir sonraki açışınızda /var kaybolacak. Bir kaplama montajı arasında bir birlik oluşturur tmpfs ve temel dosya sistemini içerir ve mevcut dosyalarda görünür değişiklikler yapmanıza olanak tanır. ro-tootf oysa bağlanabilir bir montaj parçası yenilerini boşaltabilir tmpfs yazılabilir olarak görünen klasörler ro-rootfs yollar. Sırasında overlayfs doğru olan bu (proper) dosya sistemi türü, bağlanabilir bağlama uygulanır .
Kaplamanın ve bağlanabilir montajın açıklamasına dayanarak, hiç kimse buna şaşırmadı aktif olarak kullanılmaktadırlar. Kullandığımızda bakalım ne olacak aracı kullanarak konteyneri çalıştırmak için mountsnoop itibaren bcc.
Вызов system-nspawn Çalışırken konteyneri başlatır mountsnoop.py.
Ne olduğunu görelim:
Başlatmak mountsnoop konteyner "önyükleme" yaparken, konteynerin çalışma zamanının büyük ölçüde bağlanan montaj birimine bağlı olduğunu gösterir (Sadece uzun çıkışın başlangıcı gösterilir).
öyle systemd-nspawn seçilen dosyaları sağlar procfs и sysfs yol olarak konteynere ev sahipliği yapın rootfs. hariç MS_BIND Bağlama bağlantısını ayarlayan bayrak, bağlama birimindeki diğer bazı bayraklar, ana bilgisayar ve kapsayıcı ad alanlarında yapılan değişiklikler arasındaki ilişkiyi tanımlar. Örneğin, bağlantılı bir montaj, değişiklikleri atlayabilir /proc и /sys çağrıya bağlı olarak bunları kabın içine koyun veya gizleyin.
Sonuç
Linux'un iç işleyişini anlamak imkansız bir görev gibi görünebilir, çünkü çekirdeğin kendisi büyük miktarda kod içerir ve Linux kullanıcı alanı uygulamalarını ve C kütüphanelerindeki sistem çağrı arayüzlerini bir kenara bırakır. glibc. İlerleme kaydetmenin bir yolu, sistem çağrıları ve kullanıcı alanı başlıklarının yanı sıra tablo gibi ana dahili çekirdek arayüzlerini anlamaya vurgu yaparak bir çekirdek alt sisteminin kaynak kodunu okumaktır. file_operations. Dosya işlemleri "her şey bir dosyadır" ilkesini sağlayarak bunların yönetimini özellikle keyifli hale getirir. Üst düzey dizindeki C çekirdeği kaynak dosyaları fs/ popüler dosya sistemleri ve depolama aygıtları arasında geniş ve nispeten basit uyumluluk sağlayan bir sarmalayıcı katman olan sanal dosya sistemlerinin bir uygulamasını sunar. Linux ad alanları aracılığıyla bağlama ve kaplama montajı, salt okunur kaplar ve kök dosya sistemleri oluşturmayı mümkün kılan VFS'nin büyüsüdür. Kaynak kodunun, eBPF çekirdek aracının ve arayüzünün incelenmesiyle birlikte bcc
çekirdek keşfini her zamankinden daha kolay hale getiriyor.
Arkadaşlar yazın bu yazı işinize yaradı mı? Belki herhangi bir yorumunuz veya yorumunuz var mı? Ve Linux Yönetici kursuna ilgi duyanlar davetlidir. 18 Nisan'da gerçekleşecek.
Kaynak: habr.com