LINUX.ORG.RU

хочется странного: загрузка системы с /dev/loop-устройства

 , , ,


0

1

привет, друзья!

хочу сделать чтобы (кое-где) — операционная система загружалась бы из /dev/loop-устройства ..

сейчас постараюсь всё объяснить.. но перед тем как объяснить, сначало задам главный вопрос этой темы:

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

теперь подробности:

как загружается обычная операционная система — обычных нормальных ребят (?).. вот примерно так:

0. включается комп, BIOS считывает загрузчик из жёсткого диска в оперативную память
    и передаёт ему управление;

1. загрузчик распознаёт GPT-разметку жёсткого диска
    и читает файловую систему /boot/-раздела;

2. затем загрузчик читает файлы "/boot/vmlinuz-linux" и "/boot/initramfs-linux.img",
    засовывает их в оперативную память
    и передаёт им управление;

3. согласно сценарию "initramfs" -- происходит подгрузка всяких там модулей ядра,
    и затем один из GPT-разделов
    монтируется как корневая файловая система ("/new_root/");

4. затем сценарий "initramfs" -- передаёт (через chroot) управление демону "/new_root/bin/init"
    (который ,например, быть может является ссылкой на "/new_root/lib/systemd/systemd");

5. ...

6. profit!

но а что же хочу сделать я (?).. хочу чуть-чуть странного:

весь жёсткий диск размечан как файловая система EXT4. внутри файловой системы EXT4 — установлена операционная система, и в корне — лежит большой файл «/data.img» (условно так его назовём — «data.img». хорошо?).

внутри файла «/data.img» — находится GPT-разметка. и в этой разметке находятся несколько GPT-разделов, в том числе и ещё один корневой раздел с ещё одной операционной системой.

как в этом случае будет происходить загрузка всей этой штуки:

0. включается комп, BIOS считывает загрузчик <неизвестно-откуда> в оперативную память
    и передаёт ему управление;
    (условимся -- что ТОЧНО удалось <неизвестно-откуда> загрузчик считать успешно)

1. загрузчик <неизвестно-откуда> загружает в память "vmlinuz-linux"
    и передаёт ему управление (initramfs-файла здесь нет);

2. согласно значениям Kernel-Parameters -- ядро монтирует EXT4 как корневую файловую систему (/),
    в режиме только-для-чтения;

3. затем ядро запускает файл "/bin/init" , который является ссылкой на <наш-кастумный-скрипт>;

4. <наш-кастумный-скрипт> ассоциирует файл "/data.img" с устройством "/dev/loop0"
    (напомню что внутри файла "/data.img" -- есть несколько GPT-разделов);

5. затем <наш-кастумный-скрипт> монтирует GPT-раздел "/dev/loop0p1" как "/mnt/",
    разумеется в режиме только-для-чтения;

6. а затем <наш-кастумный-скрипт> загружает в память
    новые файлы "/mnt/vmlinuz-linux" и "/mnt/initramfs-linux.img"
    и передаёт им управление (через kexec);

7. согласно сценарию нового "initramfs" -- происходит подгрузка всяких там модулей ядра,
    затем файловая система EXT4 из жёсткого диска
    монтируется как "/true_real_root/" (на этот раз -- в режиме чтение-запись),
    затем файл "/true_real_root/data.img" снова ассоциируется с устройством "/dev/loop0",
    а затем GPT-раздел "/dev/loop0p2" монтируется как новая корневая файловая система ("/new_root/");

8. затем сценарий "initramfs" -- передаёт (через chroot) управление демону "/new_root/bin/init"
    (который ,например, быть может является ссылкой на "/new_root/lib/systemd/systemd")

9. ...

10. profit!

ну и собственно повторяю вопрос:

насколько сильно будет тормозить работу операционной системы это устройство /dev/loop0 , в случае если «data.img» хранится на файловой системе EXT4?

условимся, что жёсткий диск будет SSD-типа.

# P.S.: зачем? повторяю: хочется странного.. :)

★★★★★

Последнее исправление: user_id_68054 (всего исправлений: 8)

Ответ на: комментарий от feofil

ну это всё зависит же от того насколько «хитрый» создать initrd (initramfs) файл.. прально?

user_id_68054 ★★★★★
() автор топика
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от Lincor

зачем так сложно? GRUB умеет грузить с loop.

всё дело в том что: загрузчик, который <неизвестно-откуда> и «vmlinuz-linux» который тоже <неизвестно-откуда> --- это есть как данное. это я поменять не могу.

ну и следовательно GRUB тоже поставить не могу :)

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

всё дело в том что: загрузчик, который <неизвестно-откуда> и «vmlinuz-linux» который тоже <неизвестно-откуда> --- это есть как данное.

Тебе надо поставить что-то типа kexec-tools. А потом перезагрузить систему. После холодной перезагрузки загрузится предустановленное ядро, зато после второй перезагрузки будет использоваться уже нужное тебе.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Тебе надо поставить что-то типа kexec-tools.

kexec — да, всё верно — про неё указано в стартовом посте (той-самой большой простыне :))

но судя-по-всему вы наверно намекаете мне о том что kexec можно использовать и без задействования /dev/loop ..

это верно — можно! :) .. но в этом случае я не смогу избавиться от EXT4 :-D

user_id_68054 ★★★★★
() автор топика

практически никак
Ну не замечаю я разницы
Только не SSD, а HDD
Там читать-то нечего
А рут лучше поместить в squashfs а-ля LiveCD/USB

ubuntuawp ★★
()
Ответ на: комментарий от ubuntuawp

спасиб за комментарий!

А рут лучше поместить в squashfs а-ля LiveCD/USB

в смысле — что сам файл «/data.img» лучше хранить на squashfs?

или в смысле — что внутри файла «/data.img» («/dev/loop») лучше сделать squashfs?

# P.S.: я с файловой системой-то этой — squashfs — ещё ни разу дел не имел :).. за исключеним тех случаев когда мне эту squashfs готовили без моего ведома (LiveCD/USB)

user_id_68054 ★★★★★
() автор топика
Последнее исправление: user_id_68054 (всего исправлений: 1)

так подозреваю — что будут большие накладные расходы при первоначальном создании файла «/data.img».

(например, если я буду создавать «/data.img» через утилиту «/usr/bin/dd» , а не через утилиту «/usr/bin/truncate»).

но если уже есть инициализированный файл «/data.img» (созданный без «дырок» внутри) — наверное не должено быть сильно много накладных расходов при работе с соответствующим «/dev/loop0» ?

надо где-то набрать тестовых скриптов для всего этого дела :-) .. скорость позамерять.. (а может кто-то уже замерил? ..и создал соответствующую странцу в интернетах?)

если достать такие скрипты — то можно было бы затестить loop и без-loop — и сравнить скорости.

user_id_68054 ★★★★★
() автор топика
Последнее исправление: user_id_68054 (всего исправлений: 5)

чтобы решить мою проблему — мне нужно капать в сторону какого-нибудь-там bonnie++?

user_id_68054 ★★★★★
() автор топика

насколько сильно это замедлит работу операционной системы?

почти ни насколько. А с чего должно быть замедление?

PS: вангую XY проблему.

emulek
()
Ответ на: комментарий от user_id_68054

узнал про существование этого класса проблем..

тут каждая вторая тема — проблема XY. Остальное — просто тупость.

emulek
()
Ответ на: комментарий от emulek

А с чего должно быть замедление?

ну например случилась какая-то фигня, и journald начинает генерировать свой журнал.

соответственно — журнал пишется в файл файловой системы..

а файловая система находится поверх другой файловой системы (/dev/loop0p2)...

и такой стек для каждой файловой операции.. наверняка ведь будет какое-то замедление!

ну впрочем я уже понял что нужно создать два вида ситуаций (с loop, и без loop), позапускать на них Bonnie++ и оценить деградацию.

ниже отпишу резальтаты тестов.. :-)

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

и такой стек для каждой файловой операции..

не для каждой. Журналируется только структура, потому запись в журнал будет только для rm, mkdir и создание новых файлов.

а система очень мало файлов создаёт. Ну исключение /tmp/, но его обычно в память пихают.

emulek
()
Ответ на: комментарий от user_id_68054

сам файл - и есть squashfs
sqfs просто запаковывается а-ля архив, только это фс
И сжатие лучше или bzip2, или lzma

ubuntuawp ★★
()
Ответ на: комментарий от emulek

не для каждой. Журналируется только структура, потому запись в журнал будет только для rm, mkdir и создание новых файлов.

а система очень мало файлов создаёт. Ну исключение /tmp/, но его обычно в память пихают.

если EXT4 журлализирует только структуру — то значит получается что журнал этот — вообще НЕ будет оказывать негативных побочных эффектов на нашу ситуацию :) ..

так как — после того как мы создадим файл «/data.img» — то после этого мы уже не будем что либо менять внутри файловой системы EXT4. (а все структурные изменения будут производиться только внутри /dev/loop0p2 , а не внутри EXT4).

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

если EXT4 журлализирует только структуру — то значит получается что журнал этот — вообще НЕ будет оказывать негативных побочных эффектов на нашу ситуацию :) ..

именно так всё и есть. И никаких «если».

emulek
()

вот наконец-то закончились многочасовые тесты (bonnie++)..

к сожелению затестить SSD не вышло (мало свободного места на нём), пришлось затестить обычный старенький HDD.. ..ну всё равно — пусть хотя бы так.. :)

первый рапорт — просто обычный тест файловой системы (BTRFS) поверх обычного раздела HDD:

http://i2.minus.com/ijQd3zJfG7OOa.png [тест проводился 4 раза.. а на картинке — последние 3 результата теста]

второй рапорт — файловая система (BTRFS) поверх /dev/loop поверх файловой системы EXT4 на том же HDD:

http://i7.minus.com/ibkMktoMojIb3u.png [тест проводился 4 раза.. а на картинке — последние 3 результата теста]

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

некоторые значения конечно скачут вообще непредсказуемо :) ..

..но в целом можно заметить что во втором случае (т.е.: в случае loop) — происходит стабильное замедление чуть-меньше чем-в-два-раза операций связанных с произвольным доступом (random_seek).

интересно что во втором случае (в случае с loop) — заметно также и небольшое увеличение производительности операций связанных с последовательным чтением. очевидно какой-то побочный эффект от прослойки EXT4 [кэш? чтение_наперёд?]

в целом также можно заметить и что во втором случае (в случае с loop) — результаты более хаотичны\непредсказуемы. а результаты в первом случае (в случае без loop) — наоборот более стабильные.

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

# P.S.: ну я прям как Фороникс! :-D

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от Falcon-peregrinus

а интерсно, да.. кто-нибудь пробовал WUBI?

в какой момент оно «отбирает» (образно-говоря) управление у Windows-PC и начинает дальше грузить «vmlinuz-linux»?

(или там просто обычный GRUB2?)

user_id_68054 ★★★★★
() автор топика
Последнее исправление: user_id_68054 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.