“İnode boyutu” ile “inode başına bayt” arasındaki fark nedir?


18

Aşağıdaki bilgiler man sayfasından alınmıştır, inode başına bayt ile Inode boyutu arasındaki farkı bilmek ister misiniz?

-i bytes-per-inode

Bayt / inode oranını belirtin. mke2fs, diskteki her inode başına bayt başına bayt alanı için bir inode oluşturur. İnot başına bayt oranı ne kadar büyük olursa, o kadar az düğüm oluşturulur. Bu değer genellikle dosya sisteminin blok boyutundan daha küçük olmamalıdır, çünkü o zaman çok fazla inode yapılacaktır. Bu parametre için değer.

-I inode-size

Her bir düğümün boyutunu bytes.mke2fs olarak belirtin, varsayılan olarak 256 baytlık düğümler oluşturur. 2.6.10'dan sonraki çekirdeklerde ve daha önceki bazı satıcı çekirdeklerinde, daha iyi performans için genişletilmiş öznitelikleri saklamak için 128 bayttan daha büyük kodlar kullanmak mümkündür. - inode tablosu daha fazla yer kaplar ve bu da dosya sistemindeki kullanılabilir alanı azaltır ve performansı olumsuz etkileyebilir. Dosya sistemi oluşturulduktan sonra bu değeri değiştirmek mümkün değildir.

Yanıtlar:


13

Öncelikle, inode nedir? Unix dünyasında, inode bir tür dosya girdisidir. Bir dizindeki dosya adı, bir inode için yalnızca bir etikettir (bağlantı!). Bir inode birden fazla konumda referans gösterilebilir (sabit bağlantılar!).

-i inode başına bayt (diğer adıyla inode_ratio)

Bilinmeyen bir nedenden dolayı bu parametre bazen inode başına bayt ve bazen inode_ratio olarak belgelenir . Belgelere göre, bu bayt / inode oranıdır . Çoğu insan ya da olarak belirtildiğinde daha iyi bir anlayışa sahip olacaktır (İngilizcemi özür dilerim):

  • Her X baytlık depolama için 1 inode (burada X, inot başına bayttır).
  • sığabilecek en düşük ortalama dosya boyutu.

Formül ( mke2fs kaynak koddan alınmıştır ):

inode_count = (blocks_count * blocksize) / inode_ratio

Ya da basitleştirilmiş ("bölüm boyutu" kabaca eşdeğer varsayarak blocks_count * blocksize, tahsisi kontrol etmedim):

inode_count = (partition_size_in_bytes) / inode_ratio

Not 1: FS oluşturma zamanında ( mkfs -N ...) sabit sayıda inode sağlasanız bile , değer bir orana dönüştürülür, böylece dosya sisteminin boyutunu genişlettikçe daha fazla inode sığabilirsiniz.

Not 2: Bu oranı ayarlarsanız, kullanmayı planladığınızdan önemli ölçüde daha fazla inode tahsis ettiğinizden emin olun ... gerçekten dosya sisteminizi yeniden biçimlendirmek istemezsiniz.

-I inode boyutu

Bu, dosya sisteminin sahip olabileceği her bir inode için ayrılacağı / ayıracağı bayt sayısıdır. Boşluk, inode özniteliklerini saklamak için kullanılır ( Inodes'a Giriş'i okuyun ). Ext3'te varsayılan boyut 128'dir. Ext4'te varsayılan boyut 256'dır ( extra_isizesatır içi genişletilmiş öznitelikleri depolamak ve alan sağlamak için). Linux'u okuyun : Neden inode boyutunu değiştirelim?

Not: Serbest veya kullanılmış olsun, her atanmış inode için X bayt disjpace alanı tahsis edilir; burada X = inode boyutu.


5

inode başına bayt, bu dosya sistemi için kaç inode yaratılacağını belirler; inode boyutu, bu inodeun her birinin ne kadar büyük olduğunu belirler.

Dosya sistemine çok sayıda küçük dosya (& / veya çok sayıda dizin) koymak istiyorsanız çok sayıda inode ihtiyacınız var .

AFAIK, gerçekten sadece dosyalarınız için genişletilmiş öznitelikleri saklamak istiyorsanız varsayılan 256 bayt boyutundan daha büyük inode ihtiyacınız var . psusi yorumlarda bunun doğru olmadığını söylüyor.


4
Aslında genişletilmiş öznitelikler inode yerine kendi bloklarında saklanır, bu nedenle onlar için daha büyük bir inode gerekmez. Son zamanlarda, sığacak kadar küçükse genişletilmiş öznitelikleri inode'da saklayabilme yeteneğini eklemek için son zamanlarda posta listelerinde yüzen bazı yamalar vardı, ancak henüz ana çizgiye ulaşmışlarsa, çok yakın zamanda olurdu.
psusi

1

Son derece kaba dosya sistemi şeması:

|_|__inodes__|_______________________DATA_________________________________|
  • inode-oranı / inode başına bayt = DATA alanı için inode miktarı
  • inode-size = inode alanındaki her inodeun boyutu

0

Sjas'ın cevabını gerçekten sevdim, farkın özünü veriyor.

Bu sadece kendi genişlemem (yorum yapamadığım veya oylayamadığım için, bu yığın değiştirmeden başlayarak) ve veri hacmi sırasında karar vermesi gereken kullanıcı için anlaşılabilir teknik olmayan terimlerle dengeli bir şekilde kendim için bir cevap istedim. kurulum ancak uygulama arkasında tüm ayrıntıları bilmek gerekmez.

Kişiler / Nesneler: - depolama aygıtlarındaki veri hacmi (hacimleri) - depolama aygıtları, biçimlendirilir ve bayt blokları ve adresleri sağlar - depodaki dosyaların konumları

Eylemler: depolama alanındaki işletim sistemi tarafından dosya ve klasör oluşturma / silme / yeniden adlandırma, dosya okuma / yazma / taşıma, izin değişiklikleri vb.

N bayt boyutundaki dosyanın "parçalar" (bloklar) içinde oluşturulması gerekir. Teorik olarak, dosyalar tek bayt dizileri (mantıklı olarak yapabilirler) olarak yönetilebileceğini düşünebilirse de, uzaydaki dosyaları yönetmemiz gereken tek şey, bazı dosya özelliklerini (ad vb.) Ve her dosyanın nerede başladığını belirten belirlenmiş bir dizin olacaktır. depo. Bununla birlikte, donanımın "otobüsler" ve "bloklar" ile tasarlanma şekli ve performansla ilgili hususlar, bu "parçalar" belirli boyuttadır ve ortamın blok boyutunun katlarıdır (örneğin 512 bayt, 4096 bayt) ve Bir sonraki katmana dosyaların konumları ve parçaların bulunması, belleğe yüklenmesi vb. gerektiğinde nasıl birbirine bağlandığını anlatan inodes katmanı tarafından yönetilir.

Birinde büyük bir kağıt kaydırma (hacim) varsa ve çok sayfalı belgeleri saklamak için sayfalardan (karakterler veya bilgi bitleri) yapılmış belgeler için bir bilgi deposu tasarlamak zorundaysa, gereken şey bir indekstir (belgeleri bulmak için), sayfalar (bazı basit sayfa konumlarıyla). Unix harmanlama mekanizmasında (inode) ve sayfalarda gerçek kesimde. inode boyutu indeks giriş boyutudur (az ya da çok) inode başına bayt sayfa boyutudur

Söz konusu iki ayarın değiştirilmesinin etkileri:

changin inode-size - genellikle değiştirmeye gerek yoktur, varsayılana sadık kalın (bir tartışmaya önceki yanıtta yayınlanan bağlantıya göre)

inode başına bayt - birinin birimde oluşturabileceği maksimum dosya sayısını etkiler (muhtemelen kullanılmayan baytların performansı ve "israfı")

Kağıt rulosu benzetmesine geri dönme: Belirli bir boyutta (dosya) bir belgeyi böyle bir sistemde (veya çeşitli boyutlarda birçok belgede) yazmak ve saklamak zorunda kaldığınızı düşünün - "yazma ve depolama sistemi sırasında yazdırılan sayfa boyutu "tanım ve esnek değil, aynı belge birçok sayfa gerektirebilir," sistem "sayfa boyutu çok büyükse ve belge boyutları küçükse, boşluklar ve küçük dosyaları tek bir sayfaya sığdırmak suretiyle çok fazla kağıt boşa harcanabilir. Sayfa boyutu büyükse - belge için kullanılması gereken daha az sayfa vardır ancak kullanılan son sayfada çok fazla "boşa boş alan" olabilir. Yani hepsi ... kullanılacak dosyaların boyutuna ve kaç dosyaya bağlıdır. Diğer bir husus, birçok sayfanın belgesini bulma ve getirme hızıdır.

Umarım mantıklıdır (benim için yapar) ve ext tasarımının veya mkfs seçeneklerinin herhangi bir bölümünü ciddi bir şekilde kötüye kullandımsa lütfen yorum yapın.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.