Secara berkala, untuk berpindah ke Pusat Pengedaran Pusat, saya menemu bual di pelbagai syarikat besar, terutamanya di St. Petersburg dan Moscow, untuk jawatan DevOps. Saya perhatikan bahawa banyak syarikat (banyak syarikat yang bagus, contohnya Yandex) bertanya dua soalan yang sama:
- apa itu inode;
- atas sebab apa anda boleh mendapat ralat tulis cakera (atau sebagai contoh: mengapa anda mungkin kehabisan ruang cakera, intipatinya adalah sama).
Seperti yang sering berlaku, saya pasti bahawa saya tahu topik ini dengan baik, tetapi sebaik sahaja saya mula menerangkan, jurang dalam pengetahuan menjadi jelas. Untuk mensistemkan pengetahuan saya, mengisi kekosongan dan tidak lagi memalukan diri saya, saya menulis artikel ini, mungkin ia akan berguna kepada orang lain.
Saya akan mulakan dari bawah, i.e. daripada cakera keras (kami akan membuang pemacu kilat, SSD dan perkara moden yang lain; sebagai contoh, mari kita pertimbangkan mana-mana pemacu lama 20 atau 80 gig, kerana saiz blok terdapat 512 bait).
Pemacu keras tidak tahu cara menangani bait ruang demi bait; ia dibahagikan secara bersyarat kepada blok. Penomboran blok bermula dari 0. (Ini dipanggil LBA, butiran di sini: )
Seperti yang dapat dilihat dari rajah, saya menetapkan blok LBA sebagai tahap HDD. Dengan cara ini, anda boleh melihat saiz blok cakera anda seperti ini:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Tahap di atas ialah partition, satu untuk keseluruhan cakera (sekali lagi untuk kesederhanaan). Selalunya, dua jenis penanda partition digunakan: msdos dan gpt. Sehubungan itu, msdos ialah format lama yang menyokong cakera sehingga 2Tb, gpt ialah format baharu yang mampu menangani sehingga 1 zettabait daripada blok 512 bait. Dalam kes kami, kami mempunyai partition jenis msdos, seperti yang dapat dilihat dari rajah, partition bermula dengan blok No. 1, manakala sifar digunakan untuk MBR.
Dalam partition pertama saya mencipta sistem fail ext2, saiz blok lalainya ialah 4096 bait, yang juga ditunjukkan dalam rajah. Anda boleh melihat saiz blok sistem fail seperti ini:
root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: a600bf40-f660-41f6-a3e6-96c303995479
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 65536
Block count: 261888
Reserved block count: 13094
Free blocks: 257445
Free inodes: 65525
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 63
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Fri Aug 2 15:02:13 2019
Last mount time: n/a
Last write time: Fri Aug 2 15:02:14 2019
Mount count: 0
Maximum mount count: -1
Last checked: Fri Aug 2 15:02:13 2019
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Default directory hash: half_md4
Directory Hash Seed: c0155456-ad7d-421f-afd1-c898746ccd76Parameter yang kami perlukan ialah "Saiz blok".
Sekarang bahagian yang menarik ialah bagaimana untuk membaca fail /home/serp/testfile? Fail terdiri daripada satu atau lebih blok sistem fail di mana datanya disimpan. Mengetahui nama fail, bagaimana untuk mencarinya? Blok mana yang harus saya baca?
Di sinilah inode berguna. Sistem fail ext2fs mempunyai "jadual" yang mengandungi maklumat untuk semua inod. Bilangan inod dalam kes ext2fs ditetapkan semasa mencipta sistem fail. Kami melihat nombor yang diperlukan dalam parameter "Inode count" output tune2fs, i.e. kami ada 65536 keping. Inode mengandungi maklumat yang kami perlukan: senarai blok sistem fail untuk fail yang kami cari. Bagaimana untuk mencari nombor inode untuk fail tertentu?
Nama dan nombor inod yang sepadan terkandung dalam direktori, dan direktori dalam ext2fs ialah jenis fail khas, i.e. juga mempunyai nombor inod sendiri. Untuk memecahkan lingkaran setan ini, nombor inod "tetap" "2" telah diberikan kepada direktori akar. Mari kita lihat kandungan inode nombor 2:
root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4-Feb-2014)
debugfs: stat <2>
Inode: 2 Type: directory Mode: 0755 Flags: 0x0
Generation: 0 Version: 0x00000000:00000002
User: 0 Group: 0 Size: 4096
File ACL: 0 Directory ACL: 0
Links: 3 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5d43cb51:16b61bcc -- Fri Aug 2 16:34:09 2019
atime: 0x5d43c247:b704301c -- Fri Aug 2 15:55:35 2019
mtime: 0x5d43cb51:16b61bcc -- Fri Aug 2 16:34:09 2019
crtime: 0x5d43b5c6:00000000 -- Fri Aug 2 15:02:14 2019
Size of extra inode fields: 28
BLOCKS:
(0):579
TOTAL: 1Seperti yang anda lihat, direktori yang kami perlukan terkandung dalam blok nombor 579. Di dalamnya kami akan menemui nombor nod untuk folder rumah, dan seterusnya ke bawah rantai sehingga dalam direktori serp kami melihat nombor nod untuk fail yang diminta. Jika tiba-tiba seseorang ingin menyemak sama ada nombor itu betul dan sama ada maklumat yang diperlukan ada, ia tidak sukar. Kami buat:
root@ubuntu:/# dd if=/dev/sdb1 of=/home/serp/dd_image bs=4096 count=1 skip=579
1+0 records in
1+0 records out
4096 bytes (4,1 kB) copied, 0,000184088 s, 22,3 MB/s
root@ubuntu:/# hexdump -c /home/serp/dd_imageDalam output anda boleh membaca nama fail dalam direktori.
Jadi saya sampai kepada soalan utama: "atas sebab apa ralat rakaman boleh berlaku?"
Sememangnya, ini akan berlaku jika tiada blok percuma yang tersisa dalam sistem fail. Apa yang boleh dilakukan dalam kes ini? Selain "padam apa-apa yang tidak perlu" yang jelas, anda harus ingat bahawa dalam sistem fail ext2,3 dan 4 terdapat perkara seperti "Kiraan blok tersimpan". Jika anda melihat penyenaraian di atas, kami mempunyai "13094" blok sedemikian. Ini adalah blok yang hanya boleh ditulis oleh pengguna root. tetapi jika anda perlu menyelesaikan isu itu dengan cepat, sebagai penyelesaian sementara anda boleh menyediakannya kepada semua orang, menghasilkan beberapa ruang kosong:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Itu. secara lalai, anda mempunyai 5% daripada ruang cakera tidak tersedia untuk menulis, dan memandangkan jumlah cakera moden, ini boleh menjadi ratusan gigabait.
Apa lagi yang boleh berlaku? Mungkin juga terdapat blok percuma, tetapi tiada lagi nod. Ini biasanya berlaku jika anda mempunyai sekumpulan fail pada sistem fail anda yang lebih kecil daripada saiz blok sistem fail. Memandangkan 1 inode dibelanjakan untuk 1 fail atau direktori, dan secara keseluruhan kami mempunyai (untuk sistem fail tertentu) 65536 - situasinya lebih realistik. Ini dapat dilihat dengan jelas daripada output arahan df:
serp@ubuntu:~$ df -hi
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 493K 480 492K 1% /dev
tmpfs 493K 425 493K 1% /run
/dev/xvda1 512K 240K 273K 47% /
none 493K 2 493K 1% /sys/fs/cgroup
none 493K 2 493K 1% /run/lock
none 493K 1 493K 1% /run/shm
none 493K 2 493K 1% /run/user
/dev/xvdc1 320K 4,1K 316K 2% /var
/dev/xvdb1 64K 195 64K 1% /home
/dev/xvdh1 4,0M 3,1M 940K 78% /var/www
serp@ubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 2,0G 4,0K 2,0G 1% /dev
tmpfs 395M 620K 394M 1% /run
/dev/xvda1 7,8G 2,9G 4,6G 39% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
none 5,0M 0 5,0M 0% /run/lock
none 2,0G 0 2,0G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/xvdc1 4,8G 2,6G 2,0G 57% /var
/dev/xvdb1 990M 4,0M 919M 1% /home
/dev/xvdh1 63G 35G 25G 59% /var/wwwSeperti yang boleh dilihat dengan jelas pada partition /var/www, bilangan blok percuma dalam sistem fail dan bilangan nod percuma sangat berbeza.
Sekiranya anda kehabisan inod, saya tidak akan memberitahu anda sebarang mantra, kerana... tidak ada (jika saya salah, beritahu saya). Jadi untuk partition di mana fail kecil membiak, anda harus memilih sistem fail dengan bijak. Sebagai contoh, inod btrfs tidak boleh berakhir, kerana Yang baharu dicipta secara dinamik jika perlu.
Sumber: www.habr.com