путь TL; Dr
Ваша диаграмма по существу верна.
/dev/<device> файлы
Я думаю, что самый простой способ начать отвечать на ваш вопрос - с какими /dev/<device>файлами. Скажем, у вас есть жесткий диск. Этот жесткий диск имеет таблицу разделов на основе MBR и имеет два раздела: один отформатированный ext4 с несколькими файлами на нем, а другой - для LVM. Обратите внимание, что этот ответ говорит о создании файла устройства на лету, что подразумевает, что вы используете ядро Linux. Вещи немного отличаются на других Unices.
Когда вы подключаете этот жесткий диск (или когда система обнаруживает его во время загрузки), в каталоге будет создан файл устройства /dev- обычно он называется либо /dev/sd*или /dev/hd*(в зависимости от того, какой контроллер используется для подключения диска) - * является письмо. Байты в файле устройства по существу линейно отображаются в байты на физическом диске: если вы используете инструмент для записи в начало файла устройства, эти данные также будут записаны в физическое начало физического диска.
Теперь система также понимает таблицы разделов, такие как MBR и GPT. Как только исходный файл устройства создан, он будет считан, чтобы определить, есть ли у него таблица разделов. Если это произойдет, будут созданы файлы устройства, представляющие эти разделы. Таким образом, предполагая, что исходный файл устройства был вызван /dev/sda, /dev/sda1будет создан файл устройства с именем (представляющий первый раздел в формате ext4), а также /dev/sda2устройство (представляющее второй раздел LVM). Они отображаются линейно в соответствующие разделы таким же образом, как и весь диск, то есть, если вы используете инструмент (например) для записи в начало /dev/sda2, записанные данные будут физически записаны в начало второго раздела. что на самом деле середина всего диска, потому что там начинается второй раздел.
Блоки и сектора
Это удобное время для разговоров о блоках и секторах: это просто измерения пространства на физическом диске, ничего более (по крайней мере, если я правильно понимаю). Сектор - это физическая область на жестком диске; обычно это 512 байт - 4 КБ на новых жестких дисках. Блок также является единицей измерения, он почти всегда равен 8 КБ. Когда кто-то говорит о чтении и записи блоков, это просто означает, что вместо чтения каждого байта данных по отдельности, они читают и записывают данные кусками по 8 КБ.
Файловые системы и иноды
Далее, файловые системы и inode. Файловая система - это довольно простая концепция: в начале региона, в котором находится файловая система (этот регион обычно является разделом), в файловой системе есть куча информации. Этот заголовок (также называемый суперблоком, я полагаю) сначала используется для определения, какой драйвер файловой системы следует использовать для чтения файловой системы, а затем он используется выбранным драйвером файловой системы для чтения файлов. Это, конечно, упрощение, но в основном в нем хранятся две вещи (которые могут или не могут храниться в виде двух отдельных структур данных на диске, в зависимости от типа fs): дерево каталогов и список inode. Дерево каталогов - это то, что вы видите, когда делаете lsилиtree, Дерево каталогов указывает, какие файлы и каталоги являются потомками других каталогов. Отношение файл / каталог parent-child формирует дерево каталогов UNIX, каким мы его знаем.
Но дерево каталогов включает только имена. Эти имена дополнительно связаны с номерами инодов. Номер инода содержит информацию, например, где части файла физически хранятся на диске. Индод сам по себе является просто «файлом» без имени; индекс связан с именем через дерево каталогов. Смотрите также Что такое Суперблок, Инод, Дентри и Файл?
До сих пор, у нас есть следующее объяснение: /dev/sd*файлы карты для жестких дисков, /dev/sd*#файлов карты на номер раздела #на /dev/sd*. Файловая система - это структура данных на диске, которая отслеживает дерево каталогов; обычно он хранится в разделе ( /dev/sd*#). Файловая система содержит inode; Иноды - это числа, которые представляют файлы вместе с данными, связанными с этими файлами (за исключением их имени и положения в дереве каталогов).
Стоит отметить, что файловые системы обычно отслеживают данные в блоках. Обычно дерево каталогов и список индексов хранятся в блоках, а не в байтах, а индексы указывают на блоки на диске, а не на байты. (Это может вызвать проблемы, когда файлы обычно тратят половину блока пространства, потому что файловая система выделила целый блок, но не нужно было использовать весь этот блок для последней части файла.)
Устройство картографирования
Последняя часть головоломки - это очень важный модуль в ядре Linux, называемый устройством отображения (загрузите его с помощью modprobe dm). Устройство отображения устройств в основном позволяет вам создать другой файл устройства в /dev/mapperкаталоге. Этот файл устройства затем сопоставляется с другим источником данных, возможно, преобразуется в процессе. Простейший пример - чтение части файла.
Допустим, у вас есть полный образ диска, в комплекте с таблицей разделов. Вам необходимо прочитать данные с одного из разделов в образе, но вы не можете получить доступ только к этому разделу, так как это образ полного диска, а не образ одного раздела. Решение состоит в том, чтобы найти, где в образе находится ваш раздел, а затем создать новое сопоставление файла устройства с этой частью образа диска. Вот схема:
.-------------------.
| /dev/mapper/foo | <- This is the device file created with the device mapper
.___________________.
\ /
\ /
\ / <- This is a small section of the image being mapped to
\ / the new device file
\ /
\ /
.------------------.
| diskimage.img | <- This is the full-disk image. It's a regular file.
.__________________. Notice how the mapping goes to _part_ of the file.
Другой способ думать об этом - это как конвейер преобразования (это более точная метафора для того, что происходит внутри ядра). Представьте себе конвейерную ленту. Запрос - чтение, запись и т. Д. - начинается с одного конца конвейерной ленты в файле устройства, созданном с помощью устройства отображения. Затем запрос проходит преобразование сопоставления устройств в исходный файл. В приведенном выше примере этот исходный файл является обычным файлом diskimage.img. Вот схема:
Read operation goes onto
device mapper conveyor belt
read() The device mapper transforms the read The modified read request finally
\ request by moving the requested region reaches the source file, and the data
\ Beginning of conveyor belt to read forward by some number of bytes. is retrieved from the filesystem.
\
\ .-------------------. .--------------------------. .------------------------.
\ | /dev/mapper/foo | | Transformation logic | | /path/to/diskimage.img |
\ .___________________. .___+_____+_____+_____+____. .________________________.
\-->
---------------------------------------------------------------------------------------------------------------
o o o o o o o o o o o
Обратите внимание, что на диаграмме логика преобразования, подключенная к устройству отображения, имеет мало инструментов +для манипулирования запросом чтения, когда он движется по конвейерной ленте.
Теперь мне не особо хочется копировать эту диаграмму и модифицировать ее для LVM, но в основном часть преобразования может быть чем угодно - не просто сдвигая диапазон байтов вперед. Вот как работает LVM: физический экстент LVM - это часть LVM, которая находится на диске и отслеживает, где находятся данные. Думайте об этом как о файловой системе LVM. В метафоре конвейерной ленты физический экстент является одним из исходных файлов, и преобразование - это LVM, выполняющее свою функцию, отображая запрос на логическом томе (который является самым левым элементом на конвейерной ленте) на физические данные на диске. Говоря о которых...
Я немного заржавел в своих концепциях LVM, но IIRC, Volume Group, по сути, похож на диск в LVM. Опять же, уровни IIRC, RAID и т. Д. Управляются для каждой группы томов. Таким образом, логический том похож на раздел, а логические тома - это то, что на самом деле имеют файлы устройств, представляющие их. Вы помещаете файловые системы и прочее в логические тома.
Крутая вещь в устройстве отображения карт состоит в том, что встроенная логика может быть произвольно вставлена в стек данных - все, что вам нужно сделать, это изменить имя устройства, которое вы читаете. Вот как работают зашифрованные разделы ( не схемы шифрования, которые работают на уровне файлов - те, которые используют FUSE), и так работает LVM. В данный момент я не могу вспомнить ни одного другого примера, но поверьте мне, устройство отображения карт довольно круто.
Адресация логических блоков
Я никогда не слышал об этом, поэтому я не могу предложить никакой информации об этом. Надеюсь, кто-нибудь придет и отредактирует этот ответ.