Няколко неща за 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

Необходими ни е параметърът — «Размер на блока».

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

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

Съответствието между името и номера на инода се съдържа в директорията, а директорията в ext2fs е файл от специален тип, т.е. също има свой номер инода. За да се прекъсне този порочен цикъл, на кореновата директория е назначен «фиксиран» номер инода «2». Нека видим съдържанието на инода номер 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 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_image

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

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

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

root@ubuntu:\/mnt# tune2fs -m 0 \/dev\/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)

Т.е. по подразбиране, 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, количеството свободни блокове на файловата система и количеството свободни нодов силно се различават.

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

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