Linux'taki inode'lar Hakkında Bilmek İstediğiniz Her Şey

Linux dosya sistemi inode'lara dayanır. Dosya sisteminin iç işleyişinin bu hayati parçaları genellikle yanlış anlaşılır. Tam olarak ne olduklarına ve ne yaptıklarına bakalım.

Dosya Sisteminin Öğeleri

Tanım olarak, bir dosya sisteminin dosyaları depolaması gerekir ve ayrıca dizinler içerirler. Dosyalar dizinler içinde saklanır ve bu dizinlerin alt dizinleri olabilir. Bir şey, bir yerde, tüm dosyaların dosya sistemi içinde nerede bulunduğunu, neye adlandıklarını, hangi hesaplara ait olduklarını, hangi izinlere sahip olduklarını ve daha fazlasını kaydetmelidir. Bu bilgi, diğer verileri tanımlayan veriler olduğu için meta veri olarak adlandırılır.

Linux ext4 dosya sisteminde, inode ve dizin yapıları, her dosya ve dizin için tüm meta verileri depolayan bir destekleyici çerçeve sağlamak için birlikte çalışır. Onlar bu gibi çekirdek, kullanıcı uygulamalarını veya Linux yardımcı programları, olsun, bunu gerektirir herkes için kullanılabilir meta yapmak ls, statve df.

Düğümler ve Dosya Sistemi Boyutu

Bir çift yapı olduğu doğru olsa da, bir dosya sistemi bundan daha fazlasını gerektirir. Her yapıdan binlercesi var. Her dosya ve dizin bir inode gerektirir ve her dosya bir dizinde olduğundan, her dosya da bir dizin yapısı gerektirir. Dizin yapıları, dizin girişleri veya "dişçilikler" olarak da adlandırılır.

Her bir inode, bir dosya sistemi içinde benzersiz olan bir inode numarasına sahiptir. Aynı inode numarası birden fazla dosya sisteminde görünebilir. Ancak, dosya sistemi kimliği ve inode numarası, Linux sisteminize kaç dosya sisteminin takılı olduğuna bakılmaksızın benzersiz bir tanımlayıcı oluşturmak için birleşir.

Unutmayın, Linux'ta bir sabit sürücü veya bölüm takmazsınız. Bölümdeki dosya sistemini bağlarsınız, böylece farkında olmadan birden fazla dosya sistemine sahip olmak kolaydır. Tek bir sürücüde birden çok sabit sürücünüz veya bölümünüz varsa, birden fazla dosya sisteminiz vardır. Aynı türde olabilirler - örneğin tümü ext4 - ama yine de farklı dosya sistemleri olacaktır.

Tüm düğümler tek bir tabloda tutulur. Bir inode numarası kullanarak, dosya sistemi ofseti o inode'un bulunduğu inode tablosuna kolayca hesaplar. İnode'daki "i" nin neden indeksi temsil ettiğini görebilirsiniz.

İnode numarasını içeren değişken, kaynak kodda 32 bitlik, işaretsiz uzun tamsayı olarak bildirilir. Bu, inode numarasının maksimum boyutu 2 ^ 32 olan bir tamsayı değeri olduğu anlamına gelir ve bu da 4.294.967.295'e (4 milyar inode'dan çok) hesaplanır.

Teorik maksimum budur. Uygulamada, ext4 dosya sistemindeki inode sayısı, dosya sistemi 16 KB dosya sistemi kapasitesi başına bir inode varsayılan oranında oluşturulduğunda belirlenir. Dizin yapıları, dosya sistemi içinde dosyalar ve dizinler oluşturulduğundan, dosya sistemi kullanımdayken anında oluşturulur.

Bilgisayarınızdaki bir dosya sisteminde kaç tane inode olduğunu görmek için kullanabileceğiniz bir komut vardır. -iArasında (düğüm) seçeneğini dfkomutunun o düğüm sayıları kendi görüntü çıkışı için talimat verir.

İlk sabit diskteki ilk bölümdeki dosya sistemine bakacağız, bu yüzden şunu yazıyoruz:

df -i / dev / sda1

Çıktı bize şunları verir:

• Dosya sistemi : Rapor edilen dosya sistemi.
• İnode : Bu dosya sistemindeki toplam inode sayısı.
• IUsed : Kullanılan inode sayısı.
• IFree : Kullanılabilecek kalan düğüm sayısı.
• IUse% : Kullanılan düğümlerin yüzdesi.
• Bağlanma tarihi : Bu dosya sistemi için bağlama noktası.

Bu dosya sistemindeki inode'ların yüzde 10'unu kullandık. Dosyalar, sabit sürücüde disk bloklarında saklanır. Her bir inode, temsil ettikleri dosyanın içeriğini depolayan disk bloklarına işaret eder. Milyonlarca küçük dosyanız varsa, sabit disk alanınız tükenmeden önce inode'larınız bitebilir. Ancak bu, karşılaşılması çok zor bir sorundur.

Geçmişte, e-posta mesajlarını ayrı dosyalar olarak depolayan (hızla büyük küçük dosya koleksiyonlarına yol açan) bazı posta sunucularında bu sorun vardı. Bu uygulamalar arka uçlarını veritabanlarına dönüştürdüğünde, bu sorunu çözdü. Ortalama bir ev sistemi inode'ları bitmeyecek, bu da ext4 dosya sistemi ile dosya sistemini yeniden yüklemeden daha fazla inode ekleyemeyeceğiniz için iyi.

Dosya sisteminizdeki disk bloklarının boyutunu görmek için, blockdevkomutu --getbsz(blok boyutunu al) seçeneğiyle kullanabilirsiniz:

sudo blockdev --getbsz / dev / sda

Blok boyutu 4096 bayttır.

-B4096 baytlık bir blok boyutu belirtmek için (blok boyutu) seçeneğini kullanalım ve normal disk kullanımını kontrol edelim :

df -B 4096 / dev / sda1

Bu çıktı bize şunu gösterir:

• Dosya sistemi : Rapor ettiğimiz dosya sistemi.
• 4K bloklar : Bu dosya sistemindeki toplam 4 KB blok sayısı.
• Kullanılan : Kaç adet 4K blok kullanılıyor.
• Kullanılabilir : Kullanılabilen kalan 4 KB blok sayısı.
• % Kullan : Kullanılan 4 KB bloklarının yüzdesi.
• Bağlanma tarihi : Bu dosya sistemi için bağlama noktası.

Örneğimizde, dosya depolaması (ve düğümlerin ve dizin yapılarının depolanması), bu dosya sistemindeki alanın yüzde 28'ini, düğümlerin yüzde 10'u pahasına kullandı, bu yüzden iyi durumdayız.

Inode Meta Verileri

Bir dosyanın inode sayısını görmek için kullanabileceğimiz lsile -i(inode) seçeneği:

ls -i geek.txt

Bu dosyanın inode numarası 1441801'dir, bu nedenle bu inode, bu dosyanın meta verilerini ve geleneksel olarak, dosyanın sabit sürücüde bulunduğu disk bloklarının işaretçileri tutar. Dosya parçalanmışsa, çok büyükse veya her ikisi de, inode noktalarının bazı blokları diğer disk bloklarına daha fazla işaretçi tutabilir. Ve bu diğer disk bloklarından bazıları, başka bir disk blokları setine işaretçiler de tutabilir. Bu, inode'un sabit bir boyutta olması ve disk bloklarına yönelik sınırlı sayıda işaretçi tutabilmesi sorununun üstesinden gelir.

Bu yöntemin yerini, "kapsamları" kullanan yeni bir şema aldı. Bunlar, dosyayı depolamak için kullanılan her bitişik blok kümesinin başlangıç ​​ve bitiş bloğunu kaydeder. Dosya parçalanmamışsa, yalnızca ilk bloğu ve dosya uzunluğunu kaydetmeniz gerekir. Dosya parçalanmışsa, dosyanın her bölümünün ilk ve son bloğunu kaydetmeniz gerekir. Bu yöntem (tabii ki) daha etkilidir.

Dosya sisteminizin disk bloğu işaretçileri veya uzantıları kullanıp kullanmadığını görmek istiyorsanız, bir inode'un içine bakabilirsiniz. Bunu yapmak için, debugfskomutu -R(istek) seçeneğiyle kullanacağız ve ona ilgilenilen dosyanın düğümünü geçireceğiz. Bu debugfs , inode içeriğini görüntülemek için dahili "stat" komutunu kullanmayı ister  . İnode numaraları yalnızca bir dosya sistemi içinde benzersiz olduğundan debugfs , inode'un bulunduğu dosya sistemine de söylemeliyiz .

İşte bu örnek komutun nasıl görüneceği:

sudo debugfs -R "stat" / dev / sda1

Aşağıda gösterildiği gibi, debugfskomut bilgileri inode'dan çıkarır ve bize sunar less:

Aşağıdaki bilgiler gösteriliyor:

• Inode : Baktığımız inode sayısı.
• Tür : Bu normal bir dosyadır, bir dizin veya sembolik bağlantı değildir.
• Mod : Sekizlik olarak dosya izinleri.
• Bayraklar : Farklı özellikleri veya işlevleri temsil eden göstergeler. 0x80000, "kapsamlar" bayrağıdır (daha fazlası aşağıda).
• Nesil : Bir Ağ Dosya Sistemi (NFS), bir kişi uzak dosya sistemlerine bir ağ bağlantısı üzerinden yerel makineye bağlanmış gibi eriştiğinde bunu kullanır. İnode ve nesil numaraları, bir dosya tanıtıcısı biçimi olarak kullanılır.
• Sürüm : İnode sürümü.
• Kullanıcı : Dosyanın sahibi.
• Grup : Dosyanın grup sahibi.
• Proje : Her zaman sıfır olmalıdır.
• Boyut : Dosyanın boyutu.
• Dosya ACL : Dosya erişim kontrol listesi. Bunlar, sahip grubunda olmayan kişilere kontrollü erişim vermenize izin vermek için tasarlanmıştır.
• Bağlantılar : Dosyaya yönelik sabit bağlantıların sayısı.
• Blockcount : 512 baytlık yığınlar halinde verilen bu dosyaya ayrılan sabit sürücü alanı miktarı. Dosyamıza bunların sekiz tanesi 4.096 baytlık tahsis edilmiştir. Dolayısıyla, 98 baytlık dosyamız tek bir 4.096 baytlık disk bloğunda bulunur.
• Fragment : Bu dosya parçalanmamış. (Bu eski bir bayraktır.)
• Ctime : Dosyanın oluşturulduğu saat.
• Zaman : Bu dosyaya en son erişildiği zaman.
• Mtime : Bu dosyanın en son değiştirildiği saat.
• Crtime : Dosyanın oluşturulduğu saat.
• Fazladan inode alanlarının boyutu : Ext4 dosya sistemi, format zamanında daha büyük bir disk üstü inode tahsis etme yeteneği getirdi. Bu değer, inode'un kullandığı ekstra bayt sayısıdır. Bu fazladan alan, yeni çekirdekler için gelecekteki gereksinimleri karşılamak veya genişletilmiş öznitelikleri depolamak için de kullanılabilir.
• Inode checksum : Bu inode için bir sağlama toplamı, inode'un bozuk olup olmadığını tespit etmeyi mümkün kılar.
• Uzantılar : Uzantılar kullanılıyorsa (ext4'te varsayılan olarak kullanılırlar), dosyaların disk bloğu kullanımına ilişkin meta veriler, parçalanmış bir dosyanın her bölümünün başlangıç ​​ve bitiş bloklarını gösteren iki numaraya sahiptir. Bu, bir dosyanın her bir bölümü tarafından kapsanan her disk bloğunu depolamaktan daha etkilidir. Bir uzantımız var çünkü küçük dosyamız bu blok ofsetinde bir disk bloğunda oturuyor.

Dosya Adı nerede?

Artık dosya hakkında pek çok bilgiye sahibiz, ancak fark etmiş olabileceğiniz gibi dosya adını alamadık. Bu, dizin yapısının devreye girdiği yerdir. Linux'ta, tıpkı bir dosya gibi, bir dizinin de bir inode'u vardır. Dosya verisi içeren disk bloklarına işaret etmek yerine, bir dizin inode'u, dizin yapıları içeren disk bloklarına işaret eder.

Bir inode ile karşılaştırıldığında, bir dizin yapısı bir dosya hakkında sınırlı miktarda bilgi içerir. Yalnızca dosyanın inode numarasını, adını ve adının uzunluğunu tutar.

Inode ve dizin yapısı, sizin (veya bir uygulamanın) bir dosya veya dizin hakkında bilmeniz gereken her şeyi içerir. Dizin yapısı bir dizin disk bloğundadır, dolayısıyla dosyanın bulunduğu dizini biliyoruz. Dizin yapısı bize dosya adını ve inode numarasını verir. Inode bize zaman damgaları, izinler ve dosya sisteminde dosya verilerinin nerede bulunacağı dahil olmak üzere dosya hakkında her şeyi söyler.

Dizin İnodeları

Bir dizinin inode numarasını, dosyalar için görebildiğiniz kadar kolay bir şekilde görebilirsiniz.

Aşağıdaki örnekte, kullanacağız ls ile -l(uzun biçimi), -i(inode) ve -den (dizin) seçenekleri ve görünüm workdizinine:

ls -kapaklı çalışma /

-d(Dizin) seçeneğini  kullandığımız için lsiçeriği değil dizinin kendisi hakkında rapor verir. Bu dizinin inode'u 1443016'dır.

Bunu homedizin için tekrarlamak için aşağıdakileri yazıyoruz:

ls -lid ~

Dizinin homeinode'u 1447510'dur ve workdizin, ana dizindedir. Şimdi workdizinin içeriğine bakalım . -d(Dizin) seçeneği yerine  , -a(tümü) seçeneğini kullanacağız . Bu bize genellikle gizli olan dizin girişlerini gösterecektir.

Aşağıdakileri yazıyoruz:

ls -lia işi /

-a(Hepsi) seçeneğini kullandığımız için , tek (.) Ve çift nokta (..) girişleri görüntülenir. Bu girdiler dizinin kendisini (tek nokta) ve üst dizinini (çift nokta) temsil eder.

Tek noktalı giriş için inode numarasına bakarsanız, bunun1443016 olduğunu görürsünüz - dizinin inode numarasını bulduğumuzda elde ettiğimiz inode numarası work. Ayrıca, çift nokta girişinin inode numarası, homedizinin inode numarasıyla aynıdır .

Bu nedenle cd .., dizin ağacında bir seviye yukarı çıkmak için komutu kullanabilirsiniz . Benzer şekilde, bir uygulama veya komut dosyası adının önüne geçtiğinizde   ./, kabuğa uygulamayı veya komut dosyasını nereden başlatacağını bildirirsiniz.

Düğümler ve Bağlantılar

Ele aldığımız gibi, dosya sisteminde iyi biçimlendirilmiş ve erişilebilir bir dosyaya sahip olmak için üç bileşene ihtiyaç vardır: dosya, dizin yapısı ve inode. Dosya, sabit sürücüde depolanan verilerdir, dizin yapısı dosyanın adını ve inode numarasını içerir ve inode, dosyanın tüm meta verilerini içerir.

Sembolik bağlantılar, dosyalara benzeyen dosya sistemi girdileridir, ancak gerçekten var olan bir dosya veya dizine işaret eden kısayollardır. Bunu nasıl başardıklarını ve bunu başarmak için üç unsurun nasıl kullanıldığını görelim.

Diyelim ki içinde iki dosya bulunan bir dizinimiz var: aşağıda gösterildiği gibi biri komut dosyası, diğeri ise uygulama.

-sKomut dosyasına yumuşak bir bağlantı oluşturmak için ln komutunu ve (sembolik) seçeneğini kullanabiliriz, örneğin:

ls -s my_script geek.sh

Biz bir bağlantı oluşturduk my_script.shdenilen geek.sh. Aşağıdakini yazabilir ve ls iki komut dosyasına bakmak için kullanabiliriz  :

ls -li * .sh

Girişi geek.sh mavi renkte görünür. İzin bayraklarının ilk karakteri bağlantı için "l" dir ve  ->işaret eder my_script.sh. Bütün bunlar geek.shbunun bir bağlantı olduğunu gösterir .

Muhtemelen beklediğiniz gibi, iki komut dosyası farklı inode numaralarına sahiptir. Daha şaşırtıcı olan şey ise yumuşak bağlantı geek.shorijinal komut dosyasıyla aynı kullanıcı izinlerine sahip olmamasıdır. Aslında, izinleri  geek.shçok daha serbesttir - tüm kullanıcılar tam izinlere sahiptir.

İçin dizin yapısı geek.sh, bağlantının adını ve inode'unu içerir. Bağlantıyı kullanmaya çalıştığınızda, normal bir dosya gibi onun inode'una başvurulur. Bağlantı inode'u bir disk bloğuna işaret eder, ancak dosya içeriği verilerini içermek yerine, disk bloğu orijinal dosyanın adını içerir. Dosya sistemi orijinal dosyaya yeniden yönlendirir.

Orijinal dosyayı sileceğiz ve içeriğini görüntülemek için aşağıdakileri yazdığımızda ne olacağını göreceğiz  geek.sh:

rm my_script.sh

kedi geek.sh

Sembolik bağlantı koptu ve yeniden yönlendirme başarısız oldu.

Uygulama dosyasına sabit bir bağlantı oluşturmak için şimdi aşağıdakileri yazıyoruz:

Özel uygulama geek uygulamasında

Bu iki dosyanın düğümlerine bakmak için aşağıdakileri yazıyoruz:

ls -li

Her ikisi de normal dosyalara benziyor. Hakkında hiçbir şey geek-app, lsgirişin geek.shyaptığı şekilde bir bağlantı olduğunu göstermez . Ayrıca,  geek-app orijinal dosya ile aynı kullanıcı izinlerine sahiptir. Bununla birlikte, şaşırtıcı olabilecek şey, her iki uygulamanın da aynı inode numarasına sahip olmasıdır: 1441797.

Dizin girişi geek-app"geek-app" adını ve bir inode numarasını içerir, ancak orijinal dosyanın inode numarasıyla aynıdır. Bu nedenle, her ikisi de aynı inode'u işaret eden farklı adlara sahip iki dosya sistemi girişimiz var. Aslında, herhangi bir sayıda öğe aynı inode'a işaret edebilir.

Aşağıdakini yazacağız ve statprogramı hedef dosyaya bakmak için kullanacağız :

stat özel uygulama

İki sabit bağlantının bu dosyaya işaret ettiğini görüyoruz. Bu, inode'da saklanır.

Aşağıdaki örnekte, orijinal dosyayı silip bağlantıyı gizli, güvenli bir parola ile kullanmaya çalışıyoruz:

rm özel uygulama

./geek-app fixthorsebatterystaple

Şaşırtıcı bir şekilde, uygulama beklendiği gibi çalışıyor, ama nasıl? Çalışır çünkü bir dosyayı sildiğinizde, inode yeniden kullanılabilir. Dizin yapısı, sıfır inode numarasına sahip olarak işaretlenir ve daha sonra disk blokları bu alanda depolanacak başka bir dosya için kullanılabilir.

Ancak, inode'a olan sabit bağlantıların sayısı birden fazla ise, sabit bağlantı sayısı bir azaltılır ve silinen dosyanın dizin yapısının inode numarası sıfıra ayarlanır. Sabit sürücü ve inode üzerindeki dosya içerikleri, mevcut sabit bağlantılarda hala mevcuttur.

Aşağıdakini yazıp stat'ı bir kez daha kullanacağız - bu sefer geek-app:

stat geek-app

Bu ayrıntılar, önceki statkomutla aynı inode'dan (1441797) çekilir . Bağlantı sayısı bir azaldı.

Bu inode'a tek bir sabit bağlantıya düştüğümüz için, silersek,  geek-appdosyayı gerçekten siler. Dosya sistemi inode'u serbest bırakacak ve dizin yapısını sıfır inode ile işaretleyecektir. Yeni bir dosya daha sonra sabit sürücüdeki veri deposunun üzerine yazabilir.

İLGİLİ: Linux'ta stat Komutu Nasıl Kullanılır

Inode Genel Giderleri

bu düzgün bir sistem, ancak genel giderler var. Bir dosyayı okumak için, dosya sistemi aşağıdakilerin tümünü yapmalıdır:

• Doğru dizin yapısını bulun
• İnode numarasını okuyun
• Doğru inode'u bulun
• İnode bilgilerini okuyun
• İnode bağlantılarını veya ilgili disk bloklarının kapsamlarını izleyin
• Dosya verilerini okuyun

Veriler bitişik değilse biraz daha fazla atlama gerekir.

ls Birçok dosyanın uzun formatlı bir dosya listelemesini gerçekleştirmek için yapılması gereken işi hayal edin  . Çıktısını lsoluşturmak için ihtiyaç duyduğu bilgileri elde etmek için çok fazla ileri geri var .

Elbette, dosya sistemi erişimini hızlandırmak, Linux'un mümkün olduğunca çok önleyici dosya önbelleğe alma yapmaya çalışmasının nedenidir. Bu çok yardımcı olur, ancak bazen - herhangi bir dosya sisteminde olduğu gibi - genel giderler belirgin hale gelebilir.

Şimdi nedenini anlayacaksınız.