Кое-что об 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:   <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-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 <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: 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 не могут закончиться, т.к. динамически создаются новые при необходимости.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 41

    0
    Все чаще диски в разметке GPT. Стоит изучить тему.
    Из ситуации с закончившимися inode ситуация почти безвыходная, но можно попробовать финты с уменьшением размера файловой системы и созданием нового диска с новой файловой системой. Благо дерево очень гибкое. Как временное решение — файл с временной файловой системой и устройство /dev/loop{n}.
      +2
      Ещё лучше заиспользовать XFS.
        0
        периодически ловлю подвисания на большом (8x10Tb) разделе xfs при активном обращении + проверка массива md.
        bugzilla.kernel.org/show_bug.cgi?id=201331

        не так давно поймал потерю данных после такого фриза + ребут, было очень больно.
          0
          Альтернативы? ZFS?
            +1
            > ZFS

            Да, вполне. Отлично работает уже больше полугода в продакшене. 2x4Tb, зеркалирование средствами самого ZFS (миграция живого сервака md+ext4 -> zfs без физического доступа и вменяемой консоли была очень интересным развлечением). Уже подумываю о переезде этого сервера на FreeBSD :)
              0
              И как впечатления относительно XFS? Оверхед по ОЗУ на метаданные какой? Зачем фряха понятно, это родная для неё фс, но разве на линух она была плохо портирована?
                +1
                > Оверхед по ОЗУ на метаданные какой?

                Есть, но это все подкручивается в обе стороны при желании. Там вообще можно много чего подтюнить.

                > но разве на линух она была плохо портирована

                Я лично с проблемами не сталкивался, но читал о некоторых не очень приятных багах в ZOL.
                Ну и еще, в линуксах пока нельзя (ну как, читал что вроде как можно с помощью напильника, и это работает, но там такая магия, что как-то не очень хочется на проде такое городить) полностью перевести сервер на ZFS, /boot все еще на старом добром ext4.
                И плюс общие впечатления некоторой костыльности и чрезмерной замороченности от настройки / на ZFS.
                  0

                  Ну /boot можно и на xfs завести как вариант.

            0
            Причин, конечно может быть много, но в тему статьи подходит такая: подвисание происходит из-за перестроения какого-нибудь дерева:
            — каталог с большим числом файлов в XFS — это дерево
            — свободное место отслеживается с помощью 2х деревьев: одно упорядоченно по смещению, а второе по размеру свободных (или занятых, не помню точно) областей.
              +1
              Ловили подвисания на очень активно используемом массиве в пару терабайт на XFS, лечилось дефрагментацией и настройкой предвыделения места (мы открывали кучу файлов и дописывали в них рандомно — получали больше миллиона сегментов в одном файле и зависания XFS при попытке работы с таким большим деревом фрагментов в ядре)
              +1
              Да, нельзя ли ответить на собеседовании «Если у вас XFS или NTFS, значит просто кончилось место»?
                0
                Отвечать обычно нужно то что хотят услышать.
                В данном случае хотят услышать про иноды…
                  +1
                  Да тут я сам уже напутал резерв блоков для root с inode, так что правильно всё на собеседовании спрашивают.
                  Впервые столкнулся с нехваткой inode когда ставил Linux на 4Gb SSD. Удивился, что их число зависит от размера раздела.
                0

                При этом стоит учитывать, что xfs разделы нельзя уменьшить.

                0
                Мы на файловом хранилище решали очень просто: много мелких файлов клали в zip-архив. Кроме inodes выиграли «случайно» еще несколько сотен гигов места (при упаковке «без сжатия»).

                Да, поскольку файлы раздавал nginx, то пришлось к нему прикрутить модуль распаковки zip на лету.
                  +1
                  можно про модуль подробнее?
                  0
                  zip по своей структуре тоже довольно сложно устроен. Интересно, есть ли варианты менее ресурсоёмкие при условии, что сжатие не нужно?
                    0

                    tar же?

                      +1
                      боюсь tar тут тоже далеко не самый лучший вариант. Поиск нужного файла в нём это тупо перебор блоков, причем последовательный. Да и структура tar файла подразумевает работу блоками по 512 байт. И если у нас файлы меньше, то будет куча хвостов.
                      0
                      tarball?
                        0
                        7zip есть store only режим
                          +1
                          если вы всегда пересоздаете zip архивы и не делаете append, то там ничего сложного нет.
                          линейный список имен файлов + различные атрибуты

                          –1
                          zip? В Linux? А как с правами доступа и атрибутами файлов? Они же в zip не сохраняются. И почему не loop device?
                            –1
                            Для большинства случаев будет достаточно что права можно назначить на весь архив.
                            А какая фс натянута на луп девайс?
                            0
                            Внутри zip структура файлов хранится в этом zip? Там свой маленький inode?
                              +1
                              структура хранится, в этом его плюс по сравнению с tar
                                0
                                tar хранит свою структуру архива снаружи, во внешней файловой системе? Неожиданно.
                                  +1
                                  tar не хранит каталог файлов в каком-то отдельном выделенном месте, у него вообще нет этой структуры, в tar есть информация об одном файле, потом сам файл, потом опять информация, потом файл, т.е. эта информация размазана по всему архивному файлу, и ее нельзя получить разово. В этом и есть проблема.
                                    +1
                                    Понятно. Поэтому zip может легко использоваться как виртуальная папка. А tar просто простейший архив, составленный из файлов как поезд из вагонов.
                                +1
                                В конце zip файла есть что-то вроде «содержания» архива — список структур с именем, размером и датами для каждого сжатого файла.
                              +1
                              У нас все сервера виртуализированные, поэтому проще создать новый диск с новой файловой системой и перенести данные.
                              +1

                              Длинные выводы команд лучше сокращать, например с помощью grep — сильно повысится читаемость

                                0
                                Спасибо, учту.
                                Но в данном случае сокращать надо было только последний блок, с выводом df. Т.к. к первому много отсылок.
                                +4
                                Извините меня, что такое ЦРС?
                                  0
                                  Центральные районы страны
                                    0
                                    центральная распределительная станция
                                      0
                                      Центральный рынок стройматериалов
                                      –2
                                      Можно добавить что раздел у вас на картинке начинается с сектора 1 что очень плохо. Потому что современные диски имеют физический размер серктора в 4K. А чтение по LBA не кратным физическому блоку даст пенальти по производительности. Соответственно если границы блоков файловой системы не попадут на границы физических секторов диска будет просадка производительности. Узнать размер физического сектора на диске можно с помощю «hdparm -I /dev/sda». Ну или создать раздел по смещению в 1MB от начала диска что б наверняка.
                                        +1
                                        Как видно, нужная нам директория содержится в блоке с номером 579. В ней мы найдем номер нода для папки home,
                                        А почему сделано через ноды?, когда можно было бы хранить ссылку на нужный блок, т.е. вся инфа о содержимом папки была бы в блоке этой папки, и подобной проблемы бы не возникло.
                                          +1
                                          Как минимум, тогда невозможно было бы реализовать хардлинки. Думаю есть и другие причины.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое