Linux'ta sanal dosya sistemini açıklayın
Dosya sistemi nedir? Erken bir Linux katılımcısı ve yazarı olan Robert Love'a göre, "Bir dosya sistemi, belirli bir yapıyı izleyen verilerin hiyerarşik bir depolanmasıdır." Ancak, bu açıklama VFAT (Sanal Dosya Tahsis Tablosu) için de geçerlidir.
Sanal Dosya Ayırma Tablosu
), Git ve Cassandra (bir NoSQL veritabanı). Peki dosya sistemlerini nasıl ayırt edersiniz?
Dosya sisteminin temel kavramları
Linux çekirdeği, dosya sisteminin bir varlık olmasını gerektirir, ayrıca kalıcı nesneler üzerinde open (), read () ve write () yöntemlerini uygulamalıdır ve bu varlıkların bunlarla ilişkili adlara sahip olması gerekir. Nesne yönelimli programlama perspektifinden, çekirdek genel dosya sistemini soyut bir arabirim olarak ele alır.Bu üç işlev "sanaldır" ve varsayılan tanımları yoktur. Bu nedenle, çekirdeğin varsayılan dosya sistemi uygulaması sanal dosya sistemi (VFS) olarak adlandırılır.
Açabilir (), okuyabilir () ve yazabilirsek (), bu konsol oturumunda gösterildiği gibi bir dosyadır.
VFS, ünlü Unix benzeri sistemde "her şey bir dosyadır" kavramının temelidir. Bunun ne kadar tuhaf olduğuna bir bakalım.Yukarıdaki küçük demo, / dev / console karakter cihazının gerçek çalışmasını gösteriyor. Şekil, sanal bir teletype konsolunda (tty) etkileşimli bir Bash oturumunu gösterir. Sanal konsol cihazına bir dize göndermek, sanal ekranda görüntülenmesine neden olur. Ve VFS'nin başka garip özellikleri de vardır. Örneğin, içinde ele alınabilir.
Ext4, NFS ve / proc gibi tanıdık dosya sistemlerinin tümü, dosya_işlemleri adlı C dili veri yapısında üç ana işlevin tanımını sağlar. Ek olarak, bireysel dosya sistemleri VFS işlevlerini tanıdık bir nesne yönelimli şekilde genişletir ve kapsar. Robert Love'ın belirttiği gibi, VFS'nin soyutlanması, Linux kullanıcılarının, dahili veri formatı hakkında endişelenmeden harici işletim sistemlerine veya soyut varlıklara (borular gibi) kolayca (veya onlardan) dosya kopyalamasına izin verir. Kullanıcı alanı tarafında, sistem çağrıları aracılığıyla işlem, dosyadan çekirdek veri yapısına kopyalamak için read () dosya sistemi yöntemlerinden birini kullanabilir ve ardından verileri çıkarmak için başka bir dosya sistemi yöntemi write () kullanabilir.
Temel VFS türlerine ait işlev tanımları, çekirdek kaynak kodunun fs / *. C dosyalarında ve fs / özel dosya sistemlerini içeren alt dizinlerinde bulunabilir. Çekirdek ayrıca, önyükleme işleminin başlarında gerekli olan ve bu nedenle çekirdeğin init / alt dizininde tanımlanan cgroup, / dev ve tmpfs gibi dosya sistemi benzeri varlıkları da içerir. Lütfen cgroup, / dev ve tmpfs'nin dosya_işlemlerinin üç ana işlevini çağırmadığını, doğrudan belleği okuyup yazacağını unutmayın.
Aşağıdaki şekil, kullanıcı alanının genellikle Linux sistemlerine takılı olan çeşitli dosya sistemi türlerine nasıl eriştiğini kabaca göstermektedir. Borular, dmesg ve POSIX saatleri gibi yapılar bu şekilde gösterilmemiştir, ayrıca struct file_operations gerçekleştirirler ve erişimleri de VFS katmanından geçer.
Kullanıcı alanı çeşitli dosya sistemi türlerine nasıl erişir?
VFS, sistem çağrıları ve belirli dosya işlemlerinin (ext4 ve procfs gibi) uygulamaları arasındaki bir "shim katmanı" dır. File_operations işlevi daha sonra aygıta özgü sürücülerle veya bellek erişimcileriyle iletişim kurabilir. tmpfs, devtmpfs ve cgroup file_operations kullanmaz, doğrudan belleğe erişir.
Dosya sistemleriyle ilgili temel yöntemlerin her dosya sistemi türü tarafından yeniden uygulanması gerekmediğinden, VFS'nin varlığı kodun yeniden kullanımını teşvik eder. Kod yeniden kullanımı, yazılım mühendisliğinde yaygın olarak kabul gören en iyi uygulamadır! Ne yazık ki, ancak yeniden kullanılan kod ciddi hatalar içeriyorsa, ortak yöntemleri devralan tüm uygulamalar etkilenecektir.
/ tmp: küçük bir ipucu
Sistemde bulunan VFS'yi bulmanın kolay yolu mount | grep -v sd | grep -v: / yazmaktır. Çoğu bilgisayarda, diskte yerleşik olmayan ve NFS'ye bağlı olmayan tüm VFS'leri listeleyecektir. Dosya sistemini yükleyin. Listelenen VFS bağlarından biri / tmp olmalıdır, değil mi?
Fiziksel bir depolama cihazına / tmp koymanın çılgınlık olduğunu herkes bilir! Resim: https://tinyurl.com/ybomxyfo
Depolama aygıtında / tmp'nin bırakılması neden tavsiye edilmez? / Tmp içindeki dosyalar geçici (!) Olduğundan ve depolama aygıtları bellekten daha yavaş olduğundan, tmpfs gibi bir dosya sistemi oluşturulmuştur. Ek olarak, belleğe kıyasla, fiziksel aygıtlar sık yazma ile yıpranmaya daha yatkındır. Son olarak, / tmp içindeki dosyalar hassas bilgiler içerebilir, bu nedenle her yeniden başlattığınızda bunların kaybolmasını sağlayan bir özelliktir.
Ne yazık ki, bazı Linux dağıtımlarının kurulum betikleri, varsayılan olarak depolama aygıtında hala / tmp oluşturur. Sisteminize bu olursa, umutsuzluğa kapılmayın. Sorunu çözmek için mükemmel Arch Wiki'deki basit talimatları izleyin.Tmpfs'ye ayrılan belleğin başka amaçlar için kullanılamayacağını unutmayın. Başka bir deyişle, büyük dosyalar içeren devasa bir tmpf, sistemin belleğinin bitmesine ve çökmesine neden olabilir.
Başka bir ipucu: / etc / fstab dosyasını düzenlerken, bir satırsonu karakteri ile bitirdiğinizden emin olun, aksi takdirde sistem önyükleme yapamaz. (Nasıl bildiğimi tahmin et.)
/ proc ve / sys
/ Tmp dışında, çoğu Linux kullanıcısına en çok aşina olan VFS / proc ve / sys'dir. (/ Dev, paylaşılan belleğe dayanır ve file_operations yapısı yoktur). Neden iki tane var? Daha fazla ayrıntıya bakalım.
procfs, kullanıcıya çekirdeğin anlık durumunun ve kontrol ettiği işlemlerin anlık görüntüsünü sağlar. Çekirdek / proc'ta, sağladığı tesisler hakkında kesintiler, sanal bellek ve zamanlayıcılar gibi bilgiler yayınlar. Ek olarak, / proc / sys, sysctl komutu ile yapılandırılabilen ayarların saklandığı ve kullanıcı alanı ile erişilebilen yerdir. Tek bir sürecin durumu ve istatistikleri / proc / dizinindedir. < PID > Katalogdaki rapor.
/ proc / meminfo boş bir dosyadır, ancak yine de değerli bilgiler içerir.
/ Proc dosyasının davranışı, VFS'nin diskteki dosya sisteminden farklı olabileceğini gösterir. Bir yandan, / proc / meminfo, free komutu ile görüntülenebilen bilgileri içerir. Öte yandan, hala boş! Bu nasıl olabilir? Bu durum, Cornell Üniversitesi'nden fizikçi N. David Mermin'in 1985'te yazdığı "Ay'ı Kimse Görmez mi?" Başlıklı makalesini hatırlatmaktadır. Gerçeklik ve Kuantum Teorisi. Gerçek şu ki, çekirdek, bir işlem / proc'tan veri istediğinde bellekle ilgili istatistikleri toplar ve kimse ona bakmadığında, / proc içindeki dosyaların aslında hiçbir şeyi yoktur. Mermin'in dediği gibi, "Bu temel bir kuantum teorisidir. Genel olarak konuşursak, ölçüm, ölçülen özelliğin önceden var olan değerini ortaya çıkarmaz." (Ay hakkındaki soruların cevapları bir alıştırma olarak bırakılmıştır.)
Hiçbir işlem bunlara erişmediğinde, / proc içindeki dosyalar boştur. (kaynak)
Boş procfs dosyası anlamlıdır, çünkü orada bulunan bilgiler dinamiktir. Sysfs ile durum farklıdır. / Proc ve / sys içindeki boş olmayan dosyaların sayısını karşılaştıralım.
procfs boş olmayan tek bir dosyaya sahiptir, dışa aktarılan çekirdek yapılandırması Bu bir istisnadır çünkü her başlatma için yalnızca bir kez oluşturulması gerekir. Öte yandan, / sys birçok büyük dosyaya sahiptir ve bunların çoğu bir sayfalık bellekten oluşur. Genellikle, sysfs dosyası, / proc / meminfo gibi dosyalar okunarak oluşturulan bilgi tablosunun tam tersi olan yalnızca bir sayı veya dize içerir.
Sysfs'nin amacı, çekirdek tarafından "kobject" olarak adlandırılan okunabilir ve yazılabilir nitelikleri kullanıcı alanına maruz bırakmaktır. Kobject'in tek amacı referans saymaktır: kobject'e yapılan son referans silindiğinde, sistem onunla ilişkili kaynakları geri alır. Bununla birlikte, / sys, çekirdeğin ünlü "kullanıcı alanına kararlı ABI" sını oluşturur ve içeriğinin çoğu hiçbir koşulda "yok edilemez". Ancak bu, sysfs'deki dosyaların statik olduğu anlamına gelmez, bu da uçucu nesnelerin referans sayısının tersidir.
Çekirdeğin kararlı ABI'si, herhangi bir anda gerçekte var olanı değil, / sys'de görünenleri sınırlar. Aygıtların, modüllerin, dosya sistemlerinin vb. Yapılandırılabilir ve ayarlanabilir parametrelerini nasıl ayarlayacağınızı veya okuyacağınızı öğrenmek için sysfs'deki dosyaların izinlerini listeleyin. Çekirdek dokümantasyonu bunu açıkça belirtmese de, mantıksal olarak procfs'nin de çekirdek kararlılığı ABI'nin bir parçası olduğunu vurgular.
Sysfs'deki dosyalar, varlığın her bir özniteliğini tam olarak tanımlar ve okunabilir, yazılabilir veya her ikisi birden olabilir. Dosyadaki "0", SSD'nin çıkarılabilir bir depolama cihazı olmadığını gösterir.
VFS'nin içini görmek için eBPF ve bcc araçlarını kullanın
Çekirdeğin sysfs dosyalarını nasıl yönettiğini anlamanın en kolay yolu, çalışmasını gözlemlemektir. ARM64 veya x86_64'te görüntülemenin en kolay yolu eBPF kullanmaktır. eBPF (Genişletilmiş Berkeley Paket Filtresi
genişletilmiş Berkeley Paket Filtresi
) Çekirdekte çalışan sanal makinelerden oluşur ve ayrıcalıklı kullanıcılar komut satırından sorgulama yapabilir. Çekirdek kaynak kodu, okuyucuya çekirdeğin neler yapabileceğini söyler ve eBPF aracını önyüklenmiş bir sistemde çalıştırmak, çekirdeğin gerçekte ne yaptığını gösterir.
Neyse ki, bcc araçlarıyla eBPF'ye başlamak çok kolaydır.Bu araçlar, büyük Linux dağıtımlarının yazılım paketlerinde mevcuttur ve Brendan Gregg tarafından tam olarak belgelenmiştir. Bcc aracı, küçük bir gömülü C dil parçasına sahip bir Python betiğidir, bu da iki dile aşina olan herkesin bunları kolayca değiştirebileceği anlamına gelir. Mevcut istatistiklere göre, bcc / araçlarda 80 Python betiği vardır, bu da bir sistem yöneticisinin veya geliştiricinin kendi ihtiyaçları ile ilgili mevcut betikleri bulmasını mümkün kılar.
VFS'nin çalışan bir sistemde nasıl çalıştığını anlamak için, basit bir vfscount veya vfsstat komut dosyası kullanmayı deneyin.Her saniye düzinelerce vfs_open () ve ilgili çağrının gerçekleştiğini görebilirsiniz.
vfsstat.py, gömülü C parçacıkları içeren bir Python betiğidir, yalnızca VFS işlev çağrılarını sayar.
Daha az önemli bir örnek olarak, çalışan bir sisteme bir USB bellek çubuğu takıldığında sysfs'de ne olduğuna bakalım.
USB bellek takıldığında / sys'de ne olduğunu gözlemlemek için eBPF'yi kullanın, basit ve karmaşık örnekler.
Yukarıdaki ilk basit örnekte, sysfs_create_files () komutu her çalıştırıldığında, trace.py bcc aracı komut dosyası bir mesaj yazdıracaktır. USB bellek ekleme olayına yanıt olarak sysfs_create_files () işlevinin bir kworker iş parçacığı tarafından başlatıldığını görüyoruz, ancak hangi dosyaları oluşturuyor? İkinci örnek, eBPF'nin gücünü göstermektedir. Burada, trace.py kernel traceback (-K seçeneği) ve sysfs_create_files () tarafından oluşturulan dosyaların adlarını yazdırıyor. Tek tırnak içine alınmış kod parçası, kolayca tanınabilir bir biçim dizesi de dahil olmak üzere bazı C kaynak kodudur.Sağlanan Python betiği, onu çekirdek sanal makinesinde derlemek ve çalıştırmak için LLVM tam zamanında derleyiciyi (JIT) sunar. Sysfs_create_files () işlev imzasının tamamı ikinci komutta yeniden üretilmelidir, böylece biçim dizesi parametrelerden birine başvurabilir. Bu C pasajındaki hatalar, tanınabilir C derleyici hatalarına neden olacaktır. Örneğin, -I parametresi atlanırsa sonuç "BPF metni derlenemiyor" olur. C veya Python'a aşina geliştiriciler, bcc aracını genişletmesi ve değiştirmesi kolay bulacaktır.
USB bellek çubuğunu taktıktan sonra, çekirdek izleme, PID 7711'in sysfs'de olaylar adlı bir dosya oluşturan bir kworker iş parçacığı olduğunu gösterir. Sysfs_remove_files () kullanan karşılık gelen çağrı, USB hafıza çubuğunu silmenin olay dosyasının silinmesine neden olacağını gösterir, bu da referans sayma fikri ile tutarlıdır. USB bellek takılırken (gösterilmemiştir) eBPF'de sysfs_create_link () 'i gözlemlemek, en az 48 sembolik bağlantının oluşturulduğunu gösterir.
Her neyse, olaylar dosyasının amacı nedir? __Device_add_disk () işlevini bulmak için cscope kullanmak, bunun disk_add_events () işlevini çağırdığını ve dosyaya "orta menzil" veya "ejectrequest" yazabildiğini gösterir. Burada çekirdeğin blok katmanı, "disk" in görünümü ve kaybolması hakkında kullanıcı alanını bilgilendirir. USB belleğin nasıl takıldığını kontrol etmenin ve işlemi yalnızca kaynaktan anlamaya çalışmanın bu yönteminin ne kadar hızlı olduğunu düşünün.
Salt okunur kök dosya sistemi, gömülü cihazları mümkün kılar
Aslında, hiç kimse elektrik fişini çekerek sunucuyu veya masaüstü sistemini kapatmaz. neden? Fiziksel depolama cihazına takılan dosya sistemi bekleyen (eksik) yazmalara sahip olabileceğinden ve durumunu kaydeden veri yapısı, belleğe yazılan içerikle senkronize olmayabilir. Bu olduğunda, sistem sahibinin fsck dosya sistemi kurtarma aracının bir sonraki başlangıçta çalışmasını bitirmesini beklemesi gerekecek ve en kötü durumda veriler gerçekten kaybolacaktır.
Ancak meraklılar, birçok IoT'nin ve yönlendiriciler, termostatlar ve arabalar gibi gömülü aygıtların artık Linux çalıştırdığını duyacaklar. Bu aygıtların çoğunun neredeyse hiç kullanıcı arabirimi yoktur ve bunları temiz bir şekilde "yeniden başlatmanın" bir yolu yoktur. Bataryası bitmiş bir arabayı çalıştırmayı düşünün; burada Linux çalıştıran ana cihazın güç kaynağı açılıp kapanmaya devam eder. Motor nihayet çalışmaya başladığında, sistem uzun bir fsck olmadan nasıl başlayabilir? Cevap, gömülü cihazların salt okunur bir kök dosya sistemine (veya kısaca ro-rootfs) dayanmasıdır.
ro-rootfs, gömülü sistemlerde fsck'ye sıklıkla ihtiyaç duyulmamasının sebebidir. Kaynak: https://tinyurl.com/yxoauoub
ro-rootfs pek çok avantaj sağlar, ancak bu avantajlar dayanıklılık kadar belirgin değildir. Birincisi, Linux süreci yazamazsa, kötü amaçlı yazılım / usr veya / lib yazamaz. Diğeri ise temelde değişmez bir dosya sisteminin uzak cihazların yerinde desteği için gerekli olmasıdır, çünkü destek personeli teorik olarak sahada olduğu gibi aynı yerel sisteme sahiptir. Belki de en önemli (ama aynı zamanda en ince) avantajı, ro-rootf'lerin, geliştiricileri projenin tasarım aşamasında hangi sistem nesnelerinin değişmez olduğuna karar vermeye zorlamasıdır. Ro-rootfs ile uğraşmak genellikle zahmetli ve hatta acı verici olabilir Programlama dillerindeki sabit değişkenler genellikle böyledir, ancak sağladığı faydalar bu ek yükü kolayca geri ödeyebilir.
Gömülü geliştiriciler için, salt okunur bir kök dosya sistemi oluşturmak bazı ekstra çalışmalar gerektirir ve VFS burada devreye girer. Linux'un / var içindeki dosyaların yazılabilir olması gerekir.Ayrıca, gömülü sistemlerde çalışan birçok popüler uygulama $ HOME'da yapılandırma noktası dosyaları oluşturmaya çalışır. Ana dizine yerleştirilen yapılandırma dosyalarına yönelik bir çözüm, genellikle onları önceden oluşturmak ve bunları rootf'ler halinde oluşturmaktır. / Var için bir yol, onu ayrı bir yazılabilir bölüme bağlamaktır ve / kendisi salt okunur olarak bağlanır. Bağlama veya kaplama montajı kullanmak başka bir popüler alternatiftir.
Bağlama ve kaplama montajı ve kaplarda kullanım
Bağlama montajını anlamak için adam montajını çalıştırın
bağlama montajı
Ve bindirme montajı
bindirme montajı
En iyi yol, bu yöntem yerleşik geliştiricilerin ve sistem yöneticilerinin bir yolda bir dosya sistemi oluşturmasına ve ardından bunu başka bir yolda uygulamaya sağlamasına olanak tanır. Gömülü sistemler için bu, dosyaların / var içindeki yazılamayan flash bellek aygıtında depolanabileceği anlamına gelir, ancak tmpfs'deki yol başlangıçta / var yoluna bağlanır veya bağlanır, böylece uygulama İçeriğini oraya yazmaktan çekinmeyin. / Var içindeki değişiklikler gücün bir sonraki açılışında kaybolacaktır. Yer paylaşımlı bağlama, tmpfs ile temeldeki dosya sistemi arasında bir birleşim sağlar ve ro-rootf'lerdeki mevcut dosyaların doğrudan değiştirilmesine izin verirken, bağlama bağlama yeni boş tmpfs dizinlerinin ro-rootfs yolunda yazılabilir görünmesini sağlayabilir. Yer paylaşımı dosya sistemi uygun bir dosya sistemi türü olmasına rağmen, bağlama bağlama VFS ad alanı aracı tarafından gerçekleştirilir.
Overlay mount ve bind mount açıklamasına göre, Linux konteynerlerinde yaygın olarak kullanıldıklarına kimse şaşırmayacaktır. Bcc'nin mountsnoop aracını çalıştırarak, konteyner systemd-nspawn ile başlatıldığında ne olacağını izleyelim:
Mountsnoop.py çalışırken, system-nspawn konteyneri başlatmak için çağrı yapar.
Ne olduğunu görelim:
Konteynırın "başlangıcı" sırasında mountsnoop'u çalıştırın ve konteyner çalışma zamanının büyük ölçüde bağlama montajına dayandığını görebilirsiniz. (Yalnızca uzun çıktının başlangıcını göster)
Burada systemd-nspawn, ana bilgisayarın procfs ve sysfs'sindeki seçili dosyaları rootf'lerindeki yola göre kapsayıcıya sağlar. Bağ bağlama sırasında MS_BIND bayrağının ayarlanmasına ek olarak, ana bilgisayar ad alanı ile kapsayıcıdaki değişiklikler arasındaki ilişkiyi belirlemek için bağlama sistem çağrısının diğer bazı bayrakları kullanılır. Örneğin, bağlama bağları / proc ve / sys içindeki değişiklikleri çağrıya bağlı olarak kapsayıcıya yayabilir veya gizleyebilir.
sonuç olarak
Linux'un iç yapısını anlamak imkansız bir görev gibi görünüyor, çünkü Linux kullanıcı alanı uygulamaları ve glibc gibi C kütüphanelerindeki sistem çağrı arayüzlerine ek olarak, çekirdeğin kendisi de çok fazla kod içeriyor. İlerleme yapmanın bir yolu, bir çekirdek alt sisteminin kaynak kodunu okumaktır, kullanıcı alanına yönelik sistem çağrılarını ve başlık dosyalarını ve ayrıca çekirdeğin ana dahili arayüzlerini anlamaya odaklanır Burada örnek olarak file_operations tablosunu alıyoruz. file_operations "her şey bir dosyadır" ın gerçekten çalışabilmesini sağlar, bu nedenle bunlara hakim olmak özellikle ödüllendiricidir. En üst düzey fs / dizinindeki çekirdek C kaynak dosyaları, popüler dosya sistemleri ve depolama aygıtlarının geniş ve nispeten basit birlikte çalışabilirliğini destekleyen bir shim katmanı olan sanal dosya sisteminin uygulamasını oluşturur. Linux ad alanları aracılığıyla bağlama ve aşırı bağlama, kapsayıcıları ve salt okunur kök dosya sistemlerini mümkün kılan VFS sihridir. EBPF çekirdek aracı ve onun bcc arayüzü, kaynak kodun incelenmesiyle birleştiğinde, çekirdeğin araştırılmasını her zamankinden daha kolay hale getiriyor.
