спосіб тл;
Ваша схема по суті правильна.
/dev/<device> файли
Я думаю, що найосновніший спосіб почати відповідати на ваше запитання - це які /dev/<device>файли. Скажіть, у вас жорсткий диск. Цей жорсткий диск має таблицю розділів на основі MBR, і він має два розділи, один відформатований ext4 з деякими файлами на ньому, а інший створений для LVM. Зауважте, що у цій відповіді йдеться про створення файлів на леті пристрою, що означає, що ви використовуєте ядро Linux. У інших Уніках речі дещо відрізняються .
Коли ви підключите цей жорсткий диск (або коли система виявить його під час завантаження), у каталозі буде створений файл пристрою /dev- зазвичай називається /dev/sd*або /dev/hd*( або залежно від того, який контролер використовується для підключення диска) - * є лист. Байти у файлі пристрою по суті лінійно відображаються в байти на фізичному диску: якщо ви використовуєте інструмент для запису на початок файлу пристрою, ці дані також будуть записані на фізичний початок фізичного диска.
Тепер система також розуміє таблиці розділів, такі як MBR та GPT. Після створення початкового файлу пристрою буде прочитано, щоб визначити, чи є в ньому таблиця розділів. У цьому випадку будуть створені файли пристроїв, що представляють ці розділи. Отже, припускаючи, що викликався оригінальний файл /dev/sdaпристрою, /dev/sda1буде створений файл пристрою, який називається (представляє перший розділ, форматований ext4), а також /dev/sda2пристрій (представляє другий розділ LVM). Вони відображаються лінійно до відповідних розділів так само, як і весь диск - тобто, якщо ви використовуєте інструмент (наприклад) для запису до початку /dev/sda2, записані дані будуть фізично записані на початок другого розділу , що насправді є серединою всього диска, тому що там починається другий розділ.
Блоки та сектори
Це зручний час для розмови про блоки та сектори: це просто вимірювання простору на фізичному диску, нічого більше (принаймні, якщо я правильно розумію). Сектор - це фізична область на жорсткому диску; зазвичай це 512 байт - 4 Кб на нових жорстких дисках. Блок - це також одиниця вимірювання, майже завжди це 8 Кб. Коли хтось говорить про блоки читання і запису, це просто означає, що замість того, щоб читати кожен байт даних окремо, вони читають і записують дані в шматки по 8 Кб.
Файлові системи та індекси
Далі файлові системи та вставки. Файлова система - це досить просте поняття: на початку області, в якій знаходиться файлова система (ця область, як правило, є розділом), є файлова система. Цей заголовок (також я вважаю суперблоком, я вважаю) спочатку використовується для визначення того, який драйвер файлової системи повинен використовуватися для читання файлової системи, а потім його використовує обраний драйвер файлової системи для читання файлів. Це, звичайно, спрощення, але воно, в основному, зберігає дві речі (які можуть бути, а можуть і не зберігатися як дві різні дані даних на диску, залежно від типу fs): дерево каталогів та список входів. Дерево каталогів - це те, що ви бачите, коли ви робите lsабоtree. У дереві каталогів вказано, які файли та каталоги є дітьми, які інші каталоги. Файл / каталог відносини батько-дитина формує дерево директорій UNIX таким, яким ми його знаємо.
Але дерево каталогів містить лише імена. Ці назви додатково асоціюються з номерами inode. Число inode містить інформацію про те, де фрагменти файлу фізично зберігаються на диску. Сам по собі inode - це просто "файл" без імені; inode асоціюється з іменем через дерево каталогів. Дивіться також Що таке Superblock, Inode, Dentry та File?
До сих пір, у нас є таке пояснення: /dev/sd*файли карти для жорстких дисків, /dev/sd*#файлів карти на номер розділу #на /dev/sd*. Файлова система - це структура даних на диску, яка відстежує дерево каталогів; він, як правило, зберігається в розділі ( /dev/sd*#). Файлова система містить inode; inodes - це числа, що представляють файли, а також дані, пов'язані з цими файлами (за винятком їх імені та місця в дереві каталогів).
Варто зазначити, що файлові системи, як правило, відслідковують дані в блоках. Зазвичай дерево каталогів і список inode зберігаються в блоках, а не в байтах, а inodes вказують на блоки на диску, а не на байти. (Це може спричинити проблеми, коли файли зазвичай втрачають півблоку простору, оскільки файлова система виділила цілий блок, але не потрібно було використовувати цей весь блок для останньої частини файлу.)
Картограф пристрою
Заключний фрагмент головоломки - це дуже важливий модуль у ядрі 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, група томів по суті схожа на диск у LVM. Знову ж таки, рівні IIRC, RAID тощо керуються за групою томів. Тоді логічний том є подібно до розділу, а Логічні томи - це фактично файли пристроїв, що їх представляють. Ви розміщуєте файлові системи та інше в Логічні томи.
Класна річ у картографічному пристрої пристрою полягає в тому, що побудована з ним логіка може бути вставлена довільно в стек даних - все, що вам потрібно зробити, - це змінити назву пристрою, яку ви читаєте. Ось як працюють зашифровані розділи (а не схеми шифрування, які працюють на рівні файлів - ті використовують FUSE), і ось так працює LVM. Наразі я не можу придумати жодних інших прикладів, але повірте, картограф пристрою є досить поганим.
Адресація логічного блоку
Я ніколи про це не чув, тому не можу запропонувати будь-яку інформацію про це. Сподіваємось, хтось зайде і відредагує цю відповідь.