Что такое суперблок в Линуксе. Попробуем разобраться на примере файловой системы ext(2|3|4), которая используется в линуксе по-умолчанию. Но для начала рассмотрим несколько простых понятий
После форматирования диска или раздела сектора на диске разделены на небольшие группы. Такая группа секторов называется блоком. Размер блока может быть разным и задается как параметр ключа команды форматирования. Например
mkfs -t ext3 -b 4096 /dev/sda1
ключ -b задает размер блока в байтах, в данном случае размер блока будет 4096 байт
Размер блока может быть разным. Это зависит от типа файловой системы
При выборе размера блока нужно учесть ряд моментов
Размер блока влияет на скорость чтения/записи с диска. Представим себе файл размеров в несколько сот мегабайт, который считывается с диска блоками по 1Кб. Тот же файл будет считываться быстрее если размер блока файловой системы будет 4Кб или 8Кб. Это ясно. Поэтому при форматировании имеет смысл задать блок большего размера, если планируется использовать файлы большого размера
Также верно и обратное утверждение. В случае хранения небольших файлов лучше использовать блоки минимального размера
Ядро Linux работает с размером блока файловой системы, а не с размером сектора диска (обычно 512 байт). Важно понимать, что размер блока файловой системы не может быть меньше размера сектора диска и всегда будет кратным ему. Также ядро ожидает, что размер блока файловой системы будет меньше или равно размеру системной страницы
Размер системной страницы можно увидеть выполнив команду
# getconf PAGE_SIZE
4096
Блоки, о которых мы говорили ранее обьеденяются в группы блоков, что позитивно отражается на операциях чтения/записи так как уменьшается время чтения/записи больших обьемов данных
Файловая система EXT разбивает все доспупное пространство на группы блоков равного размера. Эти группы располагаются последовательно, одна за другой
Загрузочный блок | Группа блоков 1 | Группа блоков 2 | Группа блоков 2 | Группа блоков 3 |
Количество блоков в группе неизменно и может быть расчитано по формуле
8*размер блока
Взглянем на вывод команды mke2fs
# mke2fs /dev/sdb
mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
6553600 inodes, 26214400 blocks
1310720 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
800 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Отметим то, о чем говорили выше
Также видны блоки в которых хранятся резервные копии суперблока
Самым простым определением суперблока могло бы быть следующее утверждение
Суперблок — это блок в котором хранятся метаданные файловой системы
Аналогично тому, как i-ноды хранят метаданные о файлах, суперблок хранит метаданные о файловой ситеме. Если вдруг суперблок поврежден, то не возможно будет примонтировать файловую систему. Обычно при загрузке система проверяет суперблок и при необходимости исправляет его, что в результате приводит к корректному монтированию файловых систем
Некоторые данные, которые хранятся в суперблоке. Например
Основная копия суперблока хранится в самой первой группе блоков. Она названа основной, потому что считывается системой в процессе монтирования файловой системы. Так как отсчет блоковых групп начинается с 0 то можно говорить о том, что суперблок хранится в начале блоковой группы 0
Суперблок весьма критичен для файловой системы. Поэтому в каждой блоковой группе есть копии суперблока. Это дает нам право думать, что поврежденный суперблок будет восстановлен всякий раз, когда это будет необходимо
Может показаться, что наличие в каждой блоковой группе резервных копий суперблока приводит к потреблению большого дискового пространства. Для этого в последних версиях систем была реализована функция «sparse_super» целью которой было создание резервных копий в группе блоков 0, 1, 3, 5, 7
Для этого воспользуемся командой dumpe2fs
# dumpe2fs -h /dev/sda1
dumpe2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: 5e1351eb-d016-4b6f-a2b6-d58d3009a11f
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 14958592
Block count: 59828736
Reserved block count: 2991436
Free blocks: 56390338
Free inodes: 14509726
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1009
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Apr 17 16:43:29 2013
Last mount time: Thu Aug 4 12:36:26 2016
Last write time: Thu Aug 4 12:36:26 2016
Mount count: 138
Maximum mount count: -1
Last checked: Wed Apr 17 16:43:29 2013
Check interval: 0 (<none>)
Lifetime writes: 580 GB
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
Journal inode: 8
First orphan inode: 12845071
Default directory hash: half_md4
Directory Hash Seed: 6670f391-e0d3-477f-b386-f3c71f9781d9
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00d61e12
Journal start: 19410
Еще один вывод команды показывает информацию о суперблоке
# dumpe2fs /dev/sda1 | grep -i superblock
dumpe2fs 1.42.9 (4-Feb-2014)
Primary superblock at 0, Group descriptors at 1-15
Backup superblock at 32768, Group descriptors at 32769-32783
Backup superblock at 98304, Group descriptors at 98305-98319
Backup superblock at 163840, Group descriptors at 163841-163855
Backup superblock at 229376, Group descriptors at 229377-229391
Backup superblock at 294912, Group descriptors at 294913-294927
Backup superblock at 819200, Group descriptors at 819201-819215
Backup superblock at 884736, Group descriptors at 884737-884751
Backup superblock at 1605632, Group descriptors at 1605633-1605647
Backup superblock at 2654208, Group descriptors at 2654209-2654223
Backup superblock at 4096000, Group descriptors at 4096001-4096015
Backup superblock at 7962624, Group descriptors at 7962625-7962639
Backup superblock at 11239424, Group descriptors at 11239425-11239439
Backup superblock at 20480000, Group descriptors at 20480001-20480015
Backup superblock at 23887872, Group descriptors at 23887873-23887887
Для начала нужно проверить файловую систему утилитой fsck
# fsck.ext3 -v /dev/sda1
В случае если fsck обнаружила ошибку чтения суперблока можно попробовать сделать следующее:
Для начала определим где расположены резервные копии суперблока. Для этого выполняем
# dumpe2fs /dev/sda1 | grep -i superblock
или
# mke2fs -n /dev/sda1
ключ -n говорит команде не создавать файловую систему, но показать вывод какой мог бы быть при реальном создании файловой системы
Далее восстановливаем суперблок из бекапа при помощи e2fsck
# e2fsck -b 819200 /dev/sda1
В данном случае в блоке 819200 хранится резервная копия суперблока. После применения команды пробуем снова монтировать файловую систему. Либо как вариант использовать ключ sb команды mount, который указывает на расположение копии суперблока
# mount -o -sb=819200 /dev/sda1 /mnt
В данном случае считываем копию суперблока из блока 819200