Semua yang Anda Ingin Tahu Mengenai inod di Linux

Sistem fail Linux bergantung pada inode. Bahagian penting sistem kerja sistem ini sering disalahpahami. Mari lihat dengan tepat apa yang mereka lakukan, dan apa yang mereka lakukan.

Unsur-unsur Sistem Fail

Secara definisi, sistem fail perlu menyimpan fail, dan juga mengandungi direktori. Fail disimpan di dalam direktori, dan direktori ini boleh mempunyai subdirektori. Sesuatu, di suatu tempat, harus merakam di mana semua fail berada di dalam sistem fail, apa yang mereka namakan, akaun mana yang mereka miliki, izin yang mereka miliki, dan banyak lagi. Maklumat ini disebut metadata kerana data yang menerangkan data lain.

Dalam sistem fail ext4 Linux, struktur inode dan direktori bekerjasama untuk menyediakan kerangka kerja yang menyokong semua metadata untuk setiap fail dan direktori. Mereka membuat metadata yang ada kepada sesiapa yang memerlukannya, sama ada itu kernel, aplikasi pengguna, atau utiliti Linux, seperti ls, stat, dan df.

Inod dan Saiz Sistem Fail

Walaupun benar ada sepasang struktur, sistem fail memerlukan lebih banyak daripada itu. Terdapat ribuan dan ribuan struktur masing-masing. Setiap file dan direktori memerlukan inode, dan karena setiap file ada di direktori, setiap file juga memerlukan struktur direktori. Struktur direktori juga disebut entri direktori, atau "pergigian."

Setiap inode mempunyai nombor inode, yang unik dalam sistem fail. Nombor inode yang sama mungkin muncul di lebih dari satu sistem fail. Walau bagaimanapun, ID sistem fail dan nombor inode bergabung untuk membuat pengecam yang unik, tidak kira berapa banyak sistem fail yang dipasang pada sistem Linux anda.

Ingat, di Linux, anda tidak memasang cakera keras atau partition. Anda memasang sistem fail yang ada di partisi, jadi mudah untuk mempunyai banyak sistem fail tanpa menyedarinya. Sekiranya anda mempunyai banyak cakera keras atau partisi pada satu pemacu, anda mempunyai lebih daripada satu sistem fail. Mereka mungkin jenis yang sama - semua ext4, misalnya - tetapi mereka masih akan menjadi sistem fail yang berbeza.

Semua inode disimpan dalam satu jadual. Dengan menggunakan nombor inode, sistem fail dengan mudah mengira ofset ke dalam jadual inode di mana inode itu berada. Anda dapat melihat mengapa inode "i" bermaksud indeks.

Pemboleh ubah yang mengandungi nombor inode dinyatakan dalam kod sumber sebagai 32-bit, bilangan bulat panjang yang tidak ditandatangani. Ini bermaksud nombor inode adalah nilai integer dengan ukuran maksimum 2 ^ 32, yang dihitung menjadi 4,294,967,295 — lebih dari 4 miliar inode.

Itu maksimum teori. Dalam praktiknya, bilangan inode dalam sistem fail ext4 ditentukan apabila sistem fail dibuat pada nisbah lalai satu inode per 16 KB kapasiti sistem fail. Struktur direktori dibuat dengan cepat ketika sistem file digunakan, kerana fail dan direktori dibuat dalam sistem fail.

Terdapat arahan yang boleh anda gunakan untuk melihat berapa banyak inode dalam sistem fail di komputer anda. Pilihan -i(inode) dfarahan memerintahkannya untuk menunjukkan outputnya dalam jumlah inode.

Kami akan melihat sistem fail pada partisi pertama pada cakera keras pertama, jadi kami menaip perkara berikut:

df -i / dev / sda1

Hasilnya memberi kita:

  • Sistem fail : Sistem fail yang dilaporkan.
  • Inod : Jumlah inode dalam sistem fail ini.
  • IUsed : Bilangan inode yang digunakan.
  • IFree : Bilangan inode yang tinggal untuk digunakan.
  • IUse% : Peratusan inode yang digunakan.
  • Dipasang pada : Titik pemasangan untuk sistem fail ini.

Kami telah menggunakan 10 peratus inode dalam sistem fail ini. Fail disimpan di cakera keras dalam blok cakera. Setiap inode menunjuk ke blok disk yang menyimpan kandungan fail yang mereka wakili. Sekiranya anda mempunyai berjuta-juta fail kecil, anda kehabisan inod sebelum kehabisan ruang cakera keras. Namun, itu adalah masalah yang sangat sukar untuk anda hadapi.

Pada masa lalu, beberapa pelayan mel yang menyimpan mesej e-mel sebagai fail diskrit (yang dengan cepat membawa kepada koleksi fail kecil yang besar) mempunyai masalah ini. Apabila aplikasi itu mengubah hujungnya menjadi pangkalan data, ini menyelesaikan masalahnya. Sistem rumah rata-rata tidak akan kehabisan inode, yang juga baik kerana, dengan sistem fail ext4, anda tidak dapat menambahkan lebih banyak inod tanpa memasang semula sistem fail.

Untuk melihat ukuran blok cakera pada sistem fail anda, anda dapat menggunakan blockdevperintah dengan pilihan --getbsz(dapatkan ukuran blok):

sudo blockdev --getbsz / dev / sda

Saiz blok adalah 4096 bait.

Mari gunakan pilihan -B(ukuran blok) untuk menentukan ukuran blok 4096 bait dan periksa penggunaan cakera biasa:

df -B 4096 / dev / sda1

Keluaran ini menunjukkan kepada kita:

  • Sistem fail : Sistem fail yang kami laporkan.
  • 4K-blok : Jumlah blok 4 KB dalam sistem fail ini.
  • Digunakan : Berapa banyak blok 4K yang digunakan.
  • Terdapat : Baki baki 4 KB yang tersedia untuk digunakan.
  • Gunakan% : Peratusan blok 4 KB yang telah digunakan.
  • Dipasang pada : Titik pemasangan untuk sistem fail ini.

Dalam contoh kami, penyimpanan fail (dan penyimpanan inode dan struktur direktori) telah menggunakan 28 peratus ruang pada sistem fail ini, dengan kos 10 persen dari inode, jadi kami dalam keadaan baik.

Metadata Inode

Untuk melihat nombor inode fail, kita dapat menggunakan lsdengan pilihan -i(inode):

ls -i geek.txt

Nombor inode untuk fail ini adalah 1441801, jadi inode ini menyimpan metadata untuk fail ini dan, secara tradisinya, petunjuk ke blok disk di mana fail berada di dalam cakera keras. Sekiranya fail itu terpecah-pecah, sangat besar, atau kedua-duanya, beberapa blok yang menjadi titik inode mungkin akan menunjuk lebih jauh ke blok disk yang lain. Sebilangan blok disk yang lain mungkin juga memberi petunjuk kepada sekumpulan blok cakera yang lain. Ini mengatasi masalah inode menjadi ukuran tetap dan dapat menahan sejumlah petunjuk ke blok cakera.

Kaedah itu digantikan oleh skema baru yang menggunakan "extents." Ini merekod blok awal dan akhir setiap set blok bersebelahan yang digunakan untuk menyimpan fail. Sekiranya fail tidak dibahagikan, anda hanya perlu menyimpan blok pertama dan panjang fail. Sekiranya fail itu terpecah-pecah, anda harus menyimpan blok pertama dan terakhir setiap bahagian fail. Kaedah ini (jelas) lebih berkesan.

Sekiranya anda ingin melihat sama ada sistem fail anda menggunakan pointer blok atau penunjuk, anda boleh melihat ke dalam inode. Untuk melakukannya, kami akan menggunakan debugfsperintah dengan pilihan -R(permintaan), dan meneruskannya sebagai inode fail yang menarik. Ini meminta  debugfs untuk menggunakan perintah "stat" dalamannya untuk memaparkan isi inode. Oleh kerana nombor inode hanya unik dalam sistem fail, kita juga harus memberitahu debugfs sistem fail di mana inode berada.

Inilah arahan contoh ini:

sudo debugfs -R "stat" / dev / sda1

Seperti yang ditunjukkan di bawah, debugfsperintah mengekstrak maklumat dari inode dan memberikannya kepada kami di less:

Kami menunjukkan maklumat berikut:

  • Inode : Bilangan inode yang sedang kita lihat.
  • Jenis : Ini adalah fail biasa, bukan direktori atau pautan simbolik.
  • Mod : Kebenaran fail dalam oktal.
  • Bendera : Petunjuk yang mewakili pelbagai ciri atau fungsi. 0x80000 adalah bendera "extents" (lebih lanjut mengenai ini di bawah).
  • Generasi : Sistem Fail Rangkaian (NFS) menggunakan ini apabila seseorang mengakses sistem fail jauh melalui sambungan rangkaian seolah-olah mereka dipasang di mesin tempatan. Nombor inode dan penjanaan digunakan sebagai bentuk pengendalian fail.
  • Versi : Versi inode.
  • Pengguna : Pemilik fail.
  • Kumpulan : Pemilik kumpulan fail.
  • Projek : Harus selalu sifar.
  • Saiz : Ukuran fail.
  • Fail ACL : Senarai kawalan akses fail. Ini dirancang untuk membolehkan anda memberikan akses terkawal kepada orang yang tidak berada dalam kumpulan pemilik.
  • Pautan : Jumlah pautan keras ke fail.
  • Blockcount : Jumlah ruang cakera keras yang diperuntukkan untuk fail ini, yang diberikan dalam potongan 512-byte. Fail kami telah diperuntukkan lapan daripadanya, iaitu 4,096 bait. Oleh itu, fail 98-bait kami berada dalam satu blok cakera 4,096-bait.
  • Fragment : Fail ini tidak berpecah. (Ini bendera usang.)
  • Waktu : Masa di mana fail dibuat.
  • Waktu : Masa di mana fail ini terakhir diakses.
  • Waktu : Masa di mana fail ini terakhir diubah suai.
  • Crtime : Masa di mana fail dibuat.
  • Ukuran medan inode tambahan : Sistem fail ext4 memperkenalkan kemampuan untuk memperuntukkan inode on-disk yang lebih besar pada waktu format. Nilai ini adalah bilangan byte tambahan yang digunakan inode. Ruang tambahan ini juga dapat digunakan untuk menampung keperluan masa depan untuk kernel baru atau untuk menyimpan atribut yang diperluas.
  • Inks checksum : Checksum untuk inode ini, yang memungkinkan untuk mengesan jika inode rosak.
  • Extents : Jika extents sedang digunakan (pada ext4, secara default, metadata mengenai penggunaan blok disk file mempunyai dua nombor yang menunjukkan blok awal dan akhir setiap bahagian dari sebuah fail yang terpecah-pecah. Ini lebih berkesan daripada menyimpan setiap blok cakera yang diambil oleh setiap bahagian fail. Kami mempunyai satu tahap kerana fail kecil kami terletak di satu blok disk pada blok offset ini.

Di mana Nama Fail?

Kami sekarang memiliki banyak informasi tentang file tersebut, tetapi, seperti yang anda perhatikan, kami tidak mendapatkan nama file tersebut. Di sinilah struktur direktori dimainkan. Di Linux, seperti fail, direktori mempunyai inode. Daripada menunjukkan blok disk yang mengandungi data fail, direktori inode menunjukkan blok disk yang mengandungi struktur direktori.

Dibandingkan dengan inode, struktur direktori mengandungi sejumlah maklumat mengenai fail. Ia hanya menyimpan nombor inode, nama, dan panjang nama fail.

Inode dan struktur direktori mengandungi semua yang anda (atau aplikasi) perlu ketahui mengenai fail atau direktori. Struktur direktori ada di blok disk direktori, jadi kami tahu direktori di mana file tersebut berada. Struktur direktori memberi kami nama file dan nomor inode. Inode memberitahu kita semua perkara lain mengenai fail, termasuk cap waktu, kebenaran, dan tempat mencari data fail dalam sistem fail.

Inode Direktori

Anda dapat melihat nombor inode direktori dengan semudah yang anda lihat untuk fail.

Dalam contoh berikut, kita akan menggunakan ls dengan pilihan -l(format panjang), -i(inode), dan -d(direktori), dan melihat workdirektori:

ls-tutup kerja /

Kerana kami menggunakan pilihan -d(direktori),  lslaporan pada direktori itu sendiri, bukan isinya. Inode untuk direktori ini ialah 1443016.

Untuk mengulanginya untuk homedirektori, kami taipkan yang berikut:

ls-tutup ~

Inode untuk homedirektori adalah 1447510, dan workdirektori ada di direktori utama. Sekarang, mari kita lihat kandungan workdirektori. Daripada pilihan  -d(direktori), kami akan menggunakan pilihan -a(semua). Ini akan menunjukkan kepada kita entri direktori yang biasanya tersembunyi.

Kami menaip perkara berikut:

ls -lia kerja /

Kerana kami menggunakan pilihan -a(semua), entri tunggal (.) Dan titik dua (..) akan dipaparkan. Entri ini mewakili direktori itu sendiri (titik tunggal), dan direktori induknya (titik dua).

Sekiranya anda melihat nombor inode untuk entri titik tunggal, anda itu adalah1443016 — nombor inode yang sama dengan yang kami dapatkan ketika kami menemui nombor inode untuk workdirektori. Juga, nombor inode untuk entri dua titik adalah sama dengan nombor inode untuk homedirektori.

Itulah sebabnya anda boleh menggunakan cd ..perintah untuk naik ke tingkat di pohon direktori. Begitu juga, ketika anda mendahului aplikasi atau nama skrip   ./, anda akan memberitahu shell dari mana untuk melancarkan aplikasi atau skrip tersebut.

Inod dan Pautan

Seperti yang telah kita bahas, tiga komponen diperlukan untuk memiliki file yang dapat dibentuk dengan baik dan dapat diakses dalam sistem file: file, struktur direktori, dan inode. File tersebut adalah data yang disimpan di hard drive, struktur direktori berisi nama file dan nombor inode-nya, dan inode berisi semua metadata untuk file tersebut.

Pautan simbolik adalah entri sistem fail yang kelihatan seperti fail, tetapi sebenarnya jalan pintas yang menunjuk ke fail atau direktori yang ada. Mari lihat bagaimana mereka menguruskan ini, dan bagaimana ketiga-tiga elemen itu digunakan untuk mencapainya.

Katakan kita mempunyai direktori dengan dua fail di dalamnya: satu adalah skrip, dan yang lain adalah aplikasi, seperti yang ditunjukkan di bawah.

Kita dapat menggunakan perintah ln dan pilihan -s(simbolik) untuk membuat pautan lembut ke fail skrip, seperti:

ls -s my_script geek.sh

Kami telah membuat pautan untuk my_script.shdipanggil geek.sh. Kita dapat mengetik berikut dan menggunakan  ls untuk melihat dua fail skrip:

ls -li * .sh

Entri untuk geek.sh dipaparkan dengan warna biru. Karakter pertama bendera kebenaran adalah "l" untuk pautan, dan  ->titik ke my_script.sh. Semua ini menunjukkan bahawa ia geek.shadalah pautan.

Seperti yang anda jangkakan, kedua-dua fail skrip mempunyai nombor inode yang berbeza. Namun, yang lebih mengejutkan adalah pautan lembut geek.sh, tidak mempunyai izin pengguna yang sama dengan fail skrip asal. Sebenarnya, kebenaran untuk  geek.shitu jauh lebih liberal - semua pengguna mempunyai kebenaran penuh.

Struktur direktori untuk geek.shmengandungi nama pautan dan inode-nya. Apabila anda cuba menggunakan pautan, inodnya dirujuk, seperti fail biasa. Inode pautan akan mengarah ke blok cakera, tetapi alih-alih mengandungi data kandungan fail, blok disk mengandungi nama fail asalnya. Sistem fail mengalihkan ke fail asal.

Kami akan memadamkan fail asal, dan melihat apa yang berlaku apabila kami menaip perkara berikut untuk melihat kandungan  geek.sh:

rm my_script.sh
kucing geek.sh

Pautan simbolik rosak, dan pengalihan gagal.

Kami sekarang mengetik berikut untuk membuat pautan keras ke fail aplikasi:

Dalam aplikasi geek-aplikasi khas

Untuk melihat inode untuk dua fail ini, kami taipkan perkara berikut:

ls -li

Kedua-duanya kelihatan seperti fail biasa. Tidak ada yang geek-appmenunjukkan bahawa ia adalah pautan dalam cara lspenyenaraian geek.shitu dilakukan. Plus,  geek-app mempunyai kebenaran pengguna yang sama dengan fail asal Namun, yang mungkin mengejutkan ialah kedua-dua aplikasi tersebut mempunyai nombor inode yang sama: 1441797.

Entri direktori geek-appberisi nama "geek-app" dan nombor inode, tetapi sama dengan nombor inode dari fail asal. Oleh itu, kami mempunyai dua entri sistem fail dengan nama yang berbeza yang kedua-duanya menunjukkan inode yang sama. Sebenarnya, sebilangan besar item boleh menunjukkan inode yang sama.

Kami akan menaip yang berikut dan menggunakan statprogram untuk melihat fail sasaran:

aplikasi khas stat

Kami melihat bahawa dua pautan keras menunjuk ke fail ini. Ini disimpan di inode.

Dalam contoh berikut, kami memadamkan fail asal dan cuba menggunakan pautan dengan kata laluan selamat dan rahsia:

rm-aplikasi khas
./geek-app correcthorsebatterystaple

Anehnya, aplikasi berjalan seperti yang diharapkan, tetapi bagaimana? Ia berfungsi kerana, semasa anda menghapus fail, inode bebas untuk digunakan semula. Struktur direktori ditandai sebagai bilangan inode sifar, dan blok disk kemudian tersedia untuk fail lain untuk disimpan di ruang itu.

Sekiranya bilangan pautan keras ke inode lebih besar daripada satu, namun jumlah pautan keras dikurangkan satu, dan bilangan inode struktur direktori fail yang dihapus ditetapkan menjadi sifar. Kandungan fail pada cakera keras dan inode masih tersedia untuk pautan keras yang ada.

Kami akan menaip perkara berikut dan menggunakan statistik sekali lagi — kali ini geek-app:

stat geek-aplikasi

Perincian ini diambil dari inode yang sama (1441797) seperti statperintah sebelumnya . Kiraan pautan dikurangkan satu.

Kerana kita mempunyai satu pautan keras ke inode ini, jika kita hapus  geek-app, ia benar-benar akan menghapus failnya. Sistem fail akan membebaskan inode dan menandakan struktur direktori dengan inode sifar. Fail baru kemudian boleh menimpa simpanan data pada cakera keras.

BERKAITAN: Cara Menggunakan Perintah stat di Linux

Overhead Inode

ini sistem yang kemas, tetapi ada overhead. Untuk membaca fail, sistem fail harus melakukan semua perkara berikut:

  • Cari struktur direktori yang betul
  • Baca nombor inode
  • Cari inode yang betul
  • Baca maklumat inode
  • Ikuti sama ada pautan inode atau lanjutan ke blok cakera yang berkaitan
  • Baca data fail

Sedikit lebih banyak diperlukan jika data tidak bersambung.

Bayangkan kerja yang harus dilakukan untuk  ls melakukan penyenaraian fail format panjang dari banyak fail. Terdapat banyak bolak-balik hanya untuk lsmendapatkan maklumat yang diperlukan untuk menghasilkan outputnya.

Sudah tentu, mempercepat akses sistem fail adalah mengapa Linux cuba melakukan cache fail preemptive sebanyak mungkin. Ini sangat membantu, tetapi kadang-kadang - seperti sistem fail apa pun - overhead dapat menjadi jelas.

Sekarang anda akan tahu mengapa.