Някои неща за inode

Периодично, с цел да се преместя в ЦРС, давам интервюта в различни големи компании, основно в Питера и Москва, за позицията DevOps. Забелязах, че в много компании (в много добри компании, например в Яндекса) задават два сходни въпроса:

• какво е inode;
• по какви причини може да се получи грешка при запис на диск (или например: защо може да свърши мястото на диска, основната същност е една и съща).

Както често се случва, бях сигурен, че добре познавам тази тема, но когато започнах да обяснявам — се появиха пропуски в знанията. За да систематизирам знанията си, да запълня празнотите и да не се срамувам повече, пиша тази статия, може да е полезна и на други.

Ще започна «отдолу», т.е. от твърдия диск (флашки, SSD и други съвременни устройства ще отбросим, за пример ще разгледам който и да е стар диск от 20 или 80 гигабайта, тъй като там размерът на блока е 512 байта).

Твърдият диск не може да адресира пространството си по байтове, условно е разделено на блокове. Номерирането на блоковете започва от 0. (Това се нарича LBA, подробности тук: ru.wikipedia.org/wiki/LBA)

Както се вижда от рисунката, блоковете LBA съм обозначил като ниво HDD. Между другото, можете да проверите какъв е размерът на блока на вашия диск, по следния начин:

root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512

На ниво по-високо е разделът, един за целия диск (отново за простота). Най-често се използват два типа размествания на раздели: msdos и gpt. Съответно, msdos — стар формат, поддържащ дискове до 2Tb, gpt — нов формат, способен да адресира до 1 зетабайт с 512 байтови блокове. В нашия случай имаме раздел от тип msdos, както личи от рисунката, разделът започва от блок №1, нулевият се използва за MBR.

В първия раздел създадох файловата система ext2, по подразбиране размерът на блока е 4096 байта, което също е отразено на рисунката. Можете да проверите размера на блока на файловата система по следния начин:

root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   
Last mounted on:          
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 ()
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-c898746ccd76

Необходимият параметър е „Block size“.

Сега започва интересно: как да прочетем файла /home/serp/testfile? Файлът се състои от един или повече блокове на файловата система, в които са съхранени данните му. Знаейки името на файла, как да го намерим? Какви блокове да прочетем?

Тук се появяват inode. В файловата система ext2fs има „таблица“, в която е записана информацията за всички inode. Броят на inode в случая с ext2fs се задава при създаването на файловата система. Нужните цифри можем да видим в параметъра „Inode count“ от изхода на tune2fs, т.е. имаме 65536. В inode е записана нужната ни информация: списък с блокове на файловата система за искания файл. Как да намерим номера на inode за посочения файл?

Съответствието между името и номера на inode е записано в директорията, а директорията в ext2fs е файл от специален тип, т.е. също има свой номер inode. За да разкъсаме този порочен кръг, на кореновата директория е зададен „фиксиран“ номер inode „2“. Нека погледнем съдържанието на inode с номер 2:

root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4-Feb-2014)
debugfs:  stat 

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: 1

Както се вижда, нужната ни директория се намира в блока с номер 579. В него ще намерим номера на нода за папката home и така нататък по веригата, докато в директория serp не видим номера на нода за заявения файл. Ако някой иска да провери дали номерът е верен и дали има нужната информация, това не е сложно. Правим:

root@ubuntu: /# dd if=/dev/sdb1 of=/home/serp/dd_image bs=4096 count=1 skip=579
1+0 записани
1+0 записани
4096 байта (4,1 kB) копирани, 0,000184088 с, 22,3 MB/s
root@ubuntu: /# hexdump -c /home/serp/dd_image

В изхода може да се прочетат имената на файловете в директорията.

И ето, че стигнах до основния въпрос: "по какви причини може да възникне грешка при запис"?

Естествено, това ще се случи, ако нямате свободни блокове в файловата система. Какво може да се направи в такъв случай? Освен очевидното "да изтриете нещо ненужно", трябва да помним, че в файловите системи ext2,3 и 4 съществува такова нещо, като "Брой резервирани блокове". Ако погледнете в списъка по-горе, имаме такива блокове "13094". Това са блокове, достъпни за запис само на потребителя root. Но ако е нужно бързо да решите проблема, като временно решение можете да направите тях достъпни за всички, в резултат на което ще се появи малко свободно място:

root@ubuntu: /mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Настройка на процента на резервираните блокове на 0% (0 блока)

Т.е. по подразбиране, 5% от дисковото пространство не е достъпно за запис, и като се имат предвид обемите на съвременните дискове, това могат да бъдат стотици гигабайти.

Какво още може да се случи? Още една възможна ситуация е, когато имате свободни блокове, а нодовете са свършили. Това обикновено се случва, ако във файловата система имате множество файлове с размер по-малък от размера на блока на файловата система. Имайки предвид, че за 1 файл или директория се изразходва 1 inode, а общо имаме (за тази файловата система) 65536 — ситуацията е повече от реална. Ясно може да се види от изхода на командата 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\/www

Как добре се вижда в разпределението \/var\/www, количеството свободни блокове от файловата система и количеството свободни иноди значително се различават.

В случай, че инодите свършат, нямам съвети, тъй като не съществуват (ако греша, моля, уведомете ме). Затова за дяловете, в които се натрупват много малки файлове, е необходимо да се избира правилната файловата система. Например, в btrfs инодите не могат да свършат, тъй като нови се създават динамично при необходимост.

Източник: habr.com