Лабораторная работа: исследуем inode. Часть 3. Завершение::Журнал СА 10.2017
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 8881
Комментарии: 2
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 9220
Комментарии: 5
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 16376
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 15430
Комментарии: 13
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 16468
Комментарии: 6
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Лабораторная работа: исследуем inode. Часть 3. Завершение

Архив номеров / 2017 / Выпуск №10 (179) / Лабораторная работа: исследуем inode. Часть 3. Завершение

Рубрика: Карьера/Образование /  Лабораторная работа

Без фото ПАВЕЛ ЗАКЛЯКОВ, ИТ-специалист

Лабораторная работа: исследуем inode
Часть 3. Завершение

Лабораторная работа: исследуем inode. Часть 3. ЗавершениеМожно ли «увидеть» inode? Да, в работе рассказывается, «как» и на что он «влияет»

Продолжение. Начало в [«СА» №7-8, 2017, URL: http://samag.ru/archive/article/3485] и [«СА», №9, 2017, URL: http://samag.ru/archive/article/3507], где были рассмотрены теоретические вопросы строения файловых систем (ФС) ext2-ext4, подготовка лабораторного стенда и первая часть практических заданий.

Задания для самостоятельного выполнения

Часть 2. Взаимодействие через утилиты ФС

Пункт 5. По сравнению со стандартными командами более информативный вывод по inode можно получить, используя утилиты, осуществляющие прямой доступ к ФС: debugfs, lde (linux disk editor), dumpe2fs и др.

Для экспериментов создадим новую ФС внутри файла и посмотрим, как выглядят inode в ней с точки зрения разных команд. Для того чтобы быть ближе к реальности, будем сравнивать то, что мы видим, с выводом стандартных команд взаимодействия с ФС, рассмотренных выше. Поскольку файловые системы ext2 и ext4 несколько отличаются, то файлов будет два: disk100ext2 и disk100ext4.

Пункт 5.1. Создайте пустые файлы размером по 102 400 000 байт каждый и файловые системы внутри них:

$ dd if=/dev/zero of=disk100ext2 bs=1024 count=100000

100000+0 записей считано

100000+0 записей написано

скопировано 102400000 байт (102 MB), 0,202756 c, 505 MB/c

$ dd if=/dev/zero of=disk100ext4 bs=1024 count=100000

...

$ mkfs -t ext2 -I 128 disk100ext2

...

$ mkfs -t ext4 -I 256 disk100ext4

...

Ключ «-I» задаёт размеры inode 128 и 256 байт, поскольку если размер не задать вручную, то для обеих ФС из файла mke2fs.conf будут взяты значения по умолчанию, как для ФС типа small – 128 байт, и в этом случае будут продемонстрированы улучшения, появившиеся в ext4 в сравнении с ext2.

Глубже поймем роль индексного дескриптора с точки зрения организации хранения файлов и связанной с ними информации (метаданных)

Замечание. У ФС ext2-ext4 существует большое число всевозможных функциональных опций [1], влияющих на их работу и внутреннее устройство. Большая часть из них задаётся в момент создания ФС. Некоторые опции по умолчанию оказываются включенными, другие, наоборот, выключенными. Вручную задать или отключить опцию можно с помощью ключа «-O» команды mkfs, указав в качестве его параметра через запятую нужные значения. В случае если опция (возможность) должна быть отключена, перед ней ставится знак «^», например:

$ mkfs -t ext2 -O ^ext_attr disk100ext2

До версии 1.43 дополнительные ключи «-O» игнорируются. Опция ext_attr указывает хранить расширенные атрибуты в inode. Таким образом, место хранения расширенных атрибутов в ФС, таких как ACL и SELinux (устанавливаемых через команды setfacl и chcon соответственно), напрямую зависит от её состояния.

Пункт 5.2. Оцените параметры созданных файловых систем командами:

$ dumpe2fs disk100ext2

...

$ dumpe2fs disk100ext4

Пункт 5.3. Ответьте на вопросы:

  • Какой размер блока оказался установлен по умолчанию?
  • В каких блоках размещена копия суперблока?
  • Сколько inode было создано?
  • Сколько блоков входит в группу блоков?

Пункт 5.4. Примонтируйте ФС, созданные внутри файлов disk100ext2 и disk100ext4, в директории /mnt/ext2 и /mnt/ext4 соответственно.

$ sudo mount -o loop disk100ext2 /mnt/ext2

$ sudo mount -o loop disk100ext4 /mnt/ext4

Оцените получившийся результат из ОС, определите число занятых inode в ФС командами:

$ mount

...

/home/guest/disk100ext2 on /mnt/ext2 type ext2 (rw,loop=/dev/loop0)

/home/guest/disk100ext4 on /mnt/ext4 type ext4 (rw,loop=/dev/loop1)

$ df -i

Filesystem Inodes IUsed IFree IUse% Mounted on

/home/guest/disk100ext2 25064 11 25053 1% /mnt/ext2

/home/guest/disk100ext4 24960 11 24949 1% /mnt/ext4

Пункт 5.5. Создайте файлы размером в 0 байт и несколько байт в обеих ФС.

$ touch /mnt/ext2/file0

$ touch /mnt/ext4/file0

$ echo hello > /mnt/ext2/file1

$ echo hello > /mnt/ext4/file1

Замечание. Создание файлов, как и внесение изменений в них, при отсутствии нагрузки в системе должно происходить сразу. Однако, если при запуске последующих команд, осуществляющих прямой доступ к файлам disk100ext2 иdisk100ext4 с файловой системой внутри, запись в файловую систему почему-то «не прошла» (команды «не видят» последних изменений, которые должны быть), следует выполнить сброс буферов командой /bin/sync либо произвести отмонтирование файловой системы командами:

$ sudo umount /mnt/ext2

$ sudo umount /mnt/ext4

при выполнении которых сброс произойдёт автоматически.

Пункт 5.6. Исследуйте особенности хранения файлов в ФС с помощью команд ls и stat:

$ ls -lisa /mnt/ext2

$ ls -lisa /mnt/ext4

$ stat /mnt/ext2/file0

$ stat /mnt/ext2/file1

$ stat /mnt/ext4/file0

$ stat /mnt/ext4/file1

Подумайте, почему по результатам вывода команды ls файл file0 нулевого размера в ФС ext2 занимает один блок с данными, а file1 – целых два? (Ответ на данный вопрос с пояснениями будет дан в третьей части.)

Заметили ли вы, что точность хранимых меток времени отличается от типа ФС? В случае с ФС ext2 точность указывается до секунды, а далее пишутся нули «для совместимости» формата вывода, ФС ext4 хранит значение секунд сточностью до девяти знаков после запятой.

Access: 2017-05-04 13:44:04.000000000 +0300

Access: 2017-05-04 13:44:08.024475329 +0300

Также заметьте, что в inode хранятся три метки времени, доступные пользовательским программам (на самом деле всего их четыре, подробнее об этом см. ниже):

  • Access (atime, access time) – время последнего доступа к объекту ФС. Эта метка также есть и у директорий. Как следствие, ОС меняет её метки каждый раз, как пользователь просматривает список файлов в ней. Таким образом, в ОС сбольшим числом операций с ФС, относительно быстрые операции чтения начинают смешиваться с более медленными операциями записи, от чего падает производительность. С целью повышения производительности рекомендуется монтировать ФС с опцией noatime (nodiratime).
  • Modify (mtime, modification time) – время последней модификации содержимого файла (директории).
  • Change (ctime, change time) – время последнего изменения inode (метаданных) объекта ФС.

Определите номера inode у исследуемых файлов. Напомним, что, поскольку номера с 0 по 11 зарезервированы ФС для разных целей [2], созданные файлы будут иметь номера 12 и 13.

Также, объекты разных ФС могут иметь одинаковые номера, что вы могли успешно только что наблюдать, однако ОС не испытывает затруднений, работая с разными файлами в едином дереве VFS (Virtual File System), поскольку параметр Device, выводимый командой stat, у двух разных файлов с одинаковым именем file0 отличается.

Пункт 5.7. Исследуйте те же самые файлы с помощью программы linux disk editor:

$ lde -i 12 disk100ext2

Device "disk100ext2" is mounted, be careful

User requested autodetect filesystem. Checking device ...

Found ext2fs on device.

-------------------------------------------------------------

INODE: 12 (0x0000000C)

-rw-rw-r-- user user 0 Thu May 4 13:44:04 2017

TYPE: regular file

LINKS: 1

MODEFLAGS.MODE: 010.0664

SIZE: 0

BLOCK COUNT: 2

UID: 00500 (user)

GID: 00500 (user)

ACCESS TIME: Thu May 4 13:44:04 2017

CREATION TIME: Thu May 4 13:44:04 2017

MODIFICATION TIME: Thu May 4 13:44:04 2017

DELETION TIME: Thu Jan 1 03:00:00 1970

DIRECT BLOCKS:

INDIRECT BLOCK:

DOUBLE INDIRECT BLOCK:

TRIPLE INDIRECT BLOCK:

$ lde -i 13 disk100ext2

...

$ lde -i 12 disk100ext4

$ lde -i 13 disk100ext4

Обратите внимание, что при выводе содержимого 12-го и 13-го inode ФС ext2, нигде не указаны имена файлов (file0 и file1 соответственно), то есть эта информация в них действительно не хранится. Также можно заметить и ранее упомянутую четвёртую метку времени – deletion time (время удаления). Отметьте время, установленное в ней: «начало эпохи UNIX» + «смещение часового пояса». Исследование inode после удаления файла мы произведём чуть позже.

Посмотрите, сколько блоков занимает каждый из данных файлов.

Обратите внимание, что у файла с именем file1 (inode=12 ФС=ext2) в параметре DIRECT BLOCKS содержится один номер блока, а в параметре BLOCK COUNT указано значение 4. Можете объяснить это расхождение?

Замечание. Несмотря на то что первые 128 байт inode любых размеров одинаковы, можно отметить, что linux disk editor корректно не работает, когда размер inode в ФС больше 128 байт (в нашем случае для ФС ext4 он равен 256). Какследствие, вывод последних двух команд содержит «мусор». Программа lde давно не обновлялась, и скорее всего она неправильно определяет смещение для считывания нужных 128 байт. Если создать ФС ext4 с размером inode равным 128байт, то команда работает корректно. Помимо этого, у программы также возникают проблемы при отображении занимаемых блоков в ФС ext2. Для получения истинных результатов лучше использовать debugfs или «сырое» чтение с диска.

Пункт 5.8. Исследуйте также с помощью команды lde содержимое соседних, заведомо не занятых inode на ФС ext2, например 14 и 15.

$ lde -i 14 disk100ext2

Пункт 5.9. Поскольку программа lde является отдельной программой (не входящей в основной репозиторий ОС), да и к тому же не всегда корректно показывает реальное положение дел, исследуйте те же самые файлы (созданные в п.5.5) спомощью программы debugfs, её внутренними командами stat имя_файла и stat <X>, где X – номер inode. Выход осуществляется командой quit.

$ debugfs disk100ext2

debugfs 1.41.12 (17-May-2010)

debugfs: stat file0

Inode: 12 Type: regular Mode: 0664 Flags: 0x0

Generation: 703348796 Version: 0x00000000

User: 500 Group: 500 Size: 0

File ACL: 516 Directory ACL: 0

Links: 1 Blockcount: 2

Fragment: Address: 0 Number: 0 Size: 0

ctime: 0x5933e474 -- Thu May 4 13:44:04 2017

atime: 0x5933e474 -- Thu May 4 13:44:04 2017

mtime: 0x5933e474 -- Thu May 4 13:44:04 2017

BLOCKS:

debugfs: stat <12>

...

Как видно из параметра File ACL: 516, «нашлись ранее потерянные» блоки. Блок № 516 используется как расширение inode для хранения расширенных атрибутов (метаданных). Выполнив команду imap file0 или imap <12>, можно узнать, вкаком блоке находится inode, данная информация может быть полезна при «сыром» чтении данных из ФС, если вы не планируете самостоятельно выполнить вычисление смещений.

debugfs: imap file0

Inode 12 is part of block group 0

located at block 292, offset 0x0180

debugfs – это замечательная утилита, на изучение которой стоит потратить время. С одной стороны, она имеет функционал «редактора диска», где требуется понимание строения ФС, с другой, для выполнения ручного восстановления данных (чтение содержимого удалённых файлов, исправление ошибок, возникших в результате сбоев) у неё есть много других полезных команд-аналогов, пришедших из bash'а: pwd, cd, rm, stat, cat. Схожесть имеется не только в названиях, но и в синтаксисе запуска, что сильно упрощает работу.

Например, с помощью команды cat можно просматривать содержимое файлов по имени или по номеру inode.

debugfs: cat <13>

hello

Повторите это действие.

Выводить подобным образом двоичные файлы на консоль можно, но неудобно (из-за наличия в них непечатаемых и управляющих символов). При необходимости содержимое файла можно вывести не на консоль, а сохранить во внешний файл в реальной ФС. Выполните сохранение файла file1 (inode № 13) во внешний файл file1-out и просмотрите его.

debugfs: dump <13> file1-out

debugfs: quit

$ cat file1-out

hello

Часть 3. «Сырое» чтение данных из ФС

Если задаться вопросами, а что содержится в блоке данных № 516, указанном в параметре File ACL на предыдущем шаге, да и вообще можно ли «посмотреть» на метаданные любого файла побайтно в подробностях, то без сырого чтения данных из ФС не обойтись, поскольку если ставший в своё время классикой коммерческий Norton Disk Editor позволял делать это в отношении ФС FAT, то на сегодня найти аналогичную по удобству и функционалу GNU-программу для ФС ext2-4 проблематично.

При наличии у пользователя соответствующих прав доступа на помощь приходят команды:

  • od – для просмотра содержимого файлов и дисков (блочных устройств).
  • dd – для их поблочного (побайтного) копирования.

С таким набором фактически можно прочитать (просмотреть) и скопировать что угодно, откуда угодно и куда угодно, если речь идёт о файлах, ФС и физических дисках, доступных в системе как псевдофайлы блочных устройств. Зная изтеории необходимое смещение [2] и обладая достаточным количеством времени, можно работать с блоками размером в 1, 2 или n байт. Например, попытаемся просмотреть, как хранятся расширенные атрибуты у файлов, и выясним, что же находится в блоке данных № 516, указанном в inode файла file1.

Пункт 6. Просмотрите содержимое файла file1 (в ФС ext2) с помощью команды od, выполнив нижеследующие шаги.

Пункт 6.1. Попытаться определить смещение inode № 13 можно и глядя на рис. 1, но задача эта непростая. Во-первых, нужно знать размеры отображённых там элементов. Во-вторых, резервные блоки были упомянуты вскользь, они неотображены на рисунке и ничего не было сказано про их количество. В третьих, задача расчёта смещения inode не является целью данной работы. Поэтому проще воспользоваться информацией из вывода команды dumpe2fs – для широкого взгляда на ФС и debugfs – для рассмотрения интересующего нас места в более мелком масштабе.

$ dumpe2fs disk100ext2

Group 0: (Blocks 1-8192)

Primary superblock at 1, Group descriptors at 2-2

Reserved GDT blocks at 3-258

Block bitmap at 259 (+258), Inode bitmap at 260 (+259)

Inode table at 261-501 (+260)

7675 free blocks, 1915 free inodes, 2 directories

Free blocks: 518-8192

Free inodes: 14-1928

debugfs: imap file1

Inode 13 is part of block group 0

located at block 262, offset 0x0200

Рисунок 1. Структура файловой системы ext2

Рисунок 1. Структура файловой системы ext2

Считаем inode и определим, какой дополнительный блок используется для хранения расширенных прав (списков доступа (ACL), а также какие блоки хранят данные файла.

Предварительно преобразуем 0x020016 = 51210 и вычислим 1024 * 262 + 512 = 268800.

$ od -t x1 disk100ext2 -j 268800 -A d -N 128

0268800 b4 81 f4 01 06 00 00 00 87 03 35 59 87 03 35 59

0268816 87 03 35 59 00 00 00 00 f4 01 01 00 04 00 00 00

0268832 00 00 00 00 00 00 00 00 05 02 00 00 00 00 00 00

0268848 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

*

0268896 00 00 00 00 17 5a 1e 2b 04 02 00 00 00 00 00 00

0268912 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Рисунок 2. Структура ссылок на номера блоков в inode

Рисунок 2. Структура ссылок на номера блоков в inode

В [2] находим таблицу, описывающую более точное строение inode, нежели представлено на рис. 2, откуда определяем смещение для получения байтов с номером блока, где хранятся расширенные атрибуты.

0x68

__le32

i_file_acl_lo

Lower 32-bits of extended attribute block… (Младшие 32 бита адреса блока, где хранятся расширенные атрибуты...)

0x6816=10410, данные типа __le32 занимают 4 байта. Все адреса в нашем примере 32-битные, поэтому старших 32 битов от адреса просто нет (считаем равными нулю). Смещение будет 268800 + 104 = 268904. Находим эти байты в выводе выше и переводим из формата little endian unsigned int в десятичный вид либо выведем только эти байты, а также изменим формат их отображения.

$ od -t x1 disk100ext2 -j 268904 -A d -N 4

0268904 04 02 00 00

$ od -t d disk100ext2 -j 268904 -A d -N 4

0268904 516

Итого, получился номер блока 516 – тот же самый номер, что выводила команда stat утилиты debugfs. Смещение блока будет 516 * 1024 = 528384. Читаем содержимое блока, пытаясь при этом отобразить данные в виде ASCII-символов.

$ od -t ax1 disk100ext2 -j 528384 -A d -N 1024

0528384 00 00 02 ea 02 00 00 00 01 00 00 00 cf 47 b1 6d

0528400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0528416 bel ack ` etx nul nul nul nul sp nul nul nul O G 1 m

07 06 e0 03 00 00 00 00 20 00 00 00 cf 47 b1 6d

0528432 s e l i n u x nul nul nul nul nul nul nul nul nul

73 65 6c 69 6e 75 78 00 00 00 00 00 00 00 00 00

0528448 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

*

0529376 u n c o n f i n e d _ u : o b j

75 6e 63 6f 6e 66 69 6e 65 64 5f 75 3a 6f 62 6a

0529392 e c t _ r : f i l e _ t : s 0 nul

65 63 74 5f 72 3a 66 69 6c 65 5f 74 3a 73 30 00

В первых четырёх байтах видно «магическое число» 0xEA020000 [2], хранимое в формате little endian, которое ставится в начале блока как отличительный идентификатор, сообщающий о том, что далее хранятся расширенные атрибуты. Впоследних строчках (выделено цветом) явно просматривается типичный контекст безопасности SELinux. В подтверждение догадки проверим, какой контекст был выставлен у файла /mnt/ext2/file1.

$ ls -Z /mnt/ext2/file1

-rw-rw-r--. user user unconfined_u:object_r:file_t:s0 /mnt/ext2/file1

Замечание. Первоначально блок расширенных атрибутов использовался для хранения как контекстов SElinux, так и списков контроля доступа (ACL). Поэтому если просмотреть содержимое блока, а затем у файла поменять записи списка контроля доступа (ACL-записи), то после, при повторном просмотре, можно будет заметить изменения. Например (про условии, что ACL-блок сохранит свой номер и, как следствие, смещение):

$ getfacl /mnt/ext2/file1

$ od -t ax1 disk100ext2 -j 528384 -A d -N 1024

$ setfacl -m u:root:r-- /mnt/ext2/file1

$ getfacl /mnt/ext2/file1

$ od -t ax1 disk100ext2 -j 528384 -A d -N 1024

Единственное – наглядности, как с контекстом SELinux, не получится, поскольку данные не хранятся в виде текста из ASCII-символов. Также во избежание ошибки

setfacl: /mnt/ext2/file1: Неподдерживаемая операция

ФС должна быть примонтирована с опциями user_xattr и acl, например:

$ sudo /bin/mount -o loop,user_xattr,acl disk100ext2 /mnt/ext2

По умолчанию и, соответственно, при монтировании ФС в п. 5.4 эти опции отключены.

При просмотре списка файлов в директории командой ls -l, после обычных прав доступа у файлов, имеющих ACL-записи, будет виден знак «+».

$ ls -l /mnt/ext2/file1

-rw-rw-r--+ 1 user user 6 May 4 13:44 /mnt/ext2/file1

Замечание 2. Также к расширенным атрибутам относятся и способности (см. man 7 capabilities). Вот пример установки и считывания способностей:

$ sudo setcap cap_sys_admin+ep /mnt/ext2/file1

$ getcap /mnt/ext2/file1

(Данный пример «включает» способности, использующиеся для предоставления разрешения перехвата данных с сетевых интерфейсов программам, запускаемым не от суперпользователя. В данный момент они бессмысленны, поскольку file1 – не программа.)

После установки какой-либо возможности при просмотре содержимого блока расширенных атрибутов в виде ASCII-текста вы сможете увидеть слово «capability», а разобрав соседние двоичные значения по формату, можно выяснить детали.

Пункт 6.2. Определим номер блока с данными у того же файла file1 и прочитаем его. Из рис. 2 видно, что адрес нулевого блока с данными будет храниться по смещению 40 байт от начала inode, то есть смещение от начала диска составит значение, полученное на шаге 6.1, – 268800 + 40 = 268840. Считываем 4 байта и переводим их должным образом в десятичный вид.

$ od -t x1 disk100ext2 -j 268840 -A d -N 4

0268840 05 02 00 00

$ od -t d disk100ext2 -j 268840 -A d -N 4

0268840 517

Получился номер блока с данными 517 – тот же самый номер, что выводила команда stat утилиты debugfs. Смещение блока будет 517 * 1024 = 529408. Читаем содержимое блока (например, первые 10 символов), отображая данные в виде ASCII-символов.

$ od -t a disk100ext2 -j 529408 -A d -N 1024

0529408 h e l l o nl nul nul nul ...

Пункт 6.3. Исследуйте, какое значение хранится в бай-тах, отведённых для адреса первого блока с данными. Из рис. 2 видно, что это значение следует сразу же за байтами, отведёнными для адреса первого блока с данными. То есть ксмещению можно просто добавить 4. Также, если интересно, можно посчитать адреса смещения соседних блоков и «заглянуть» в них, задавшись вопросом: пустые они или нет? Конечно, наличие нулевых символов по всему блоку ни о чём не говорит и правильным будет определять, занят блок или нет, обратившись к битовой карте блоков, но исследование её выходит за рамки темы данной работы.

Пункт 7. Вычислите момент (два соседних значения размера файла), когда будет переход к хранению информации с использованием косвенной адресации. Обратившись к рис. 3, можно увидеть, что это произойдёт, когда будет израсходован объём 12 блоков данных, адресуемых 12 адресами прямой адресации.

Пункт 7.1. Используя команды и знания, применявшиеся ранее, проверьте на практике полученное в п. 7 значение.

Пункт 8. Для ФС с блоком данных размером 1024 байта выведите формулу и произведите теоретический расчёт размера файла, начиная с которого будет использоваться двойная косвенная адресация.

Пункт 8.1. Повторите расчёт для ФС с блоком данных размером 4096 байт.

Пункт 9. Просмотрите дату и время, а затем удалите файл /mnt/ext2/file1.

$ date -R

Thu, 04 May 2017 14:51:32 +0300

$ rm /mnt/ext2/file1

Поскольку в обычных условиях данные inode после удаления файла не стираются, то по ранее определённому его номеру и вычисленному на его основе смещению произведите просмотр содержимого inode в части deletion time. Время хранится в формате __le32 в секундах с начала эпохи UNIX по смещению 0x14 (подробнее об этом и других полях см. [2]).

Соответствует время удаления файла тому, что было записано в его inode, когда файл существовал?

Пункт 10. Повторите пункты заданий частей 2 и 3 для ФС ext4, оцените, что изменилось.

Пункт 11. Вернём систему к первоначальному состоянию. Исходя из того, что по ходу выполнения заданий все файлы и директории создавались в директории ~/dir1, удалим её со всем содержимым.

$ rm -rf ~/dir1

Если вы создавали объекты ФС в других местах – удалите их. Будет ещё один повод повторно пробежаться по выполненным заданиям и уяснить, что же вы проделали и какие объекты создавали.

Стереть историю команд в bash можно командой:

$ history -c

При этом будут удалены все команды из истории, в том числе и те, что ранее существовали в файле ~/bash_history до проведения данной работы.

Ответ на вопрос, заданный в п.5.6: пустой файл по результатам вывода программы stat занимает два блока на диске, потому как данные отображаются порциями по 512, а при размере блока 1024 порций будет две и отобразиться число 2, а не1. Вторая часть вопроса: не важно, один блок или два, почему файл занимает не ноль? Дело в том, что в системе по умолчанию «включен SELinux», который автоматически добавляет файловым объектам контекст безопасности (вы егомогли увидеть в п. 6.1). Поскольку в ФС ext2 мы специально задали inode размером 128 байт при её создании, то хранить его негде, кроме как в отдельном блоке. Создай мы ФС с inode размером 256 или больше байт, данные скорее всего уместились бы в нём и дополнительный блок не потребовался бы. Можете это проверить. Также и при размере inode в 128 байт возможно не использовать дополнительный блок. Для этого надо в корне отключить selinux (чтобы команда getenforce выводила Disabled). Сделать это можно тремя путями: либо установить в файле /etc/selinux/config параметр SELINUX=disabled и перезагрузить систему, либо передать ядру через загрузчик GRUB параметр selinux=0, либо перекомпилировать ядро без поддержки SELinux и загрузиться с него. У старых файлов контекст безопасности никуда не исчезнет, а создаваемые новые будут без него, и тогда файл размера 0 будет занимать 0 блоков на диске.

Заключение

В результате выполнения заданий работы и подготовки к ним вы освежили в памяти устройство отдельных частей ФС ext2-ext4 и имели возможность более близко познакомиться с такой её частью, как inode, если не сказать иначе – «взглянуть внутрь». В ходе выполнения практических занятий вы должны были глубже понять роль индексного дескриптора с точки зрения организации хранения файлов и связанной с ними информации (метаданных), также вы имели возможность оценить различные количественные параметры за счёт использования стандартных программ и «сырого чтения», научились взаимодействовать с файлами, имеющими «необычные» символы в имени. Вы должны были «увидеть», где и как хранятся расширенные атрибуты файлов, а также что значит хранение данных (например, коротких ссылок) внутри inode. Возможно, вы открыли для себя новые утилиты и команды. Полученные знания вам, несомненно, пригодятся, когда вы столкнётесь с проблемой восстановления целостности ФС и «потерянной информации» и в ряде других ситуаций.

  1. Об опциях ФС ext2-4 – http://man7.org/linux/man-pages/man5/ext4.5.html.
  2. Ext4 Disk Layout – https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru