Безопасно ли использовать loop-устройство для обхода EBUSY на блочном устройстве, лежащем в основе device-mapper?

Question

Я пытаюсь включить начало блочного устройства диска (область GPT) в линейное отображение device-mapper в режиме только для чтения. Это блочное устройство также содержит мою корневую файловую систему, поэтому раздел, в котором она находится, будет использоваться одновременно с существованием отображения. Это необходимо, чтобы я мог передать части (но не весь) этого же диска в Windows 10, работающую под QEMU, для использования там. Я не намерен когда-либо делать так, чтобы какие-либо секции диска одновременно записывались на нескольких ядрах, но раздел Windows, а также ESP (не смонтирован в Linux) могут быть.

Для визуализации (указаны номера разделов):

<Таблицы разделов> <1. (U)EFI системный раздел> <2. Мусор, остатки от MSR раздела> <3. Windows 10> <4. Работающая Linux система> <Резервные данные GPT>

Итак, я хочу передать начало диска, а также первый и третий разделы, возможно, мне также понадобится конец диска. Доступ на запись должен быть разрешен только к разделам, а не к внешним частям диска.

Несколько лет назад я узнал о device-mapper в другой ситуации и пересмотрел его документацию. Воодушевленный, я пошел своим путем и создал отображение, начиная с начала, и в конце концов столкнулся с текущей проблемой: при попытке создать устройство маппера dmsetup передал ошибку EBUSY. Я подозреваю, что это произошло из-за того, что одно из подустройств блочного устройства диска, блочное устройство раздела с моей установкой Linux, в настоящее время используется.

В целях устранения неполадок я воссоздал ситуацию на RAM-диске (считается ли теперь brd Linux Arcanum?), который (насколько я помню) заставлял операции терпеть неудачу так же, как они терпели неудачу на настоящем диске:

#!/bin/sh # Очевидно, потребуется root или, возможно, CAPs.
[ -b /dev/ram0 ] && exit 1
   # В этом сценарии я полагаюсь на то, что brd не используется, а /dev/ram0 создан.
modprobe brd rd_nr=1 rd_size=261120 max_part=2 && [ -b /dev/ram0 ] || exit 2
sgdisk -a=8 -n=0:0:+100M -t=0:ef00 -n=0 -t=0:8304 /dev/ram0
# В p1 не нужна файловая система для демонстрации.
mkfs.ext4 -i 6144 -O ext_attr,flex_bg,inline_data,metadata_csum,sparse_super2 /dev/ram0p2
   # Просто пример файловой системы, взятой из моей истории команд shell.
mkdir /tmp/ExampleMountpoint || exit 3
mount /dev/ram0p2 /tmp/ExampleMountpoint || exit 4
dmsetup create --readonly Example1 --table '0 33 linear /dev/ram0 0' #Вывод:
# device-mapper: ошибка перезагрузки ioctl на Example1 (253:0): устройство или ресурс заняты
# Команда не выполнена.
   # Код выхода - 1, но сообщение об ошибке соответствует EBUSY.
   # Как и следовало ожидать, добавление -f не помогает.
umount /tmp/ExampleMountpoint
dmsetup create --readonly Example2 --table '0 33 linear /dev/ram0 0'
   # Это работает, но мне нужно, чтобы это работало с установленным разделом.
ls -l /dev/mapper/Example2
dmsetup remove Example2
# rm /tmp/ExampleMountpoint

На другом вопросе StackExchange, который я нашел в начале — я искал его двадцать дней назад, когда спрашивал на одном Linux форуме об этом (безуспешно), затем искал его сегодня снова, так и не смог найти его снова — был ответ, который показал, что я мог бы обойти статус EBUSY, используя устройство-петлю в качестве посредника перед настоящим блочным устройством диска:

mount /dev/ram0p2 /tmp/ExampleMountpoint # Перемонтировать.
LoopDev=$(losetup --show -f /dev/ram0)
dmsetup create --readonly Example2 --table '0 68 linear /dev/loop0 0'
   # Примечание: меньшее, чем 68сек, вызывает ошибку sgdisk вместо вывода таблицы.
   # Это может быть ошибкой, оно должно, по-моему, снижаться до уровня 1+32+32+1 или даже просто 33s.
sgdisk -Pp "$LoopDev" # Это должно напечатать несколько предупреждений, затем созданную выше таблицу разделов.
losetup -d "$LoopDev"
umount /tmp/ExampleMountpoint
rm /tmp/ExampleMountpoint

Итак, при перенаправлении блочного устройства диска через устройство-петлю, dmsetup будет действовать корректно, а не выдавать ошибку. Заботясь о своих данных (хотя у меня есть снимок на отдельном диске), я теперь задаюсь вопросом, безопасно ли это делать и даст ли это ожидаемые результаты в общем случае. (Среди них, предотвращение повреждения раздела 4 и GPI, а также предоставление доступа на запись к разделам 1 и 3 через VM). Есть ли какие-то, не знаю, дополнительные подводные камни выравнивания ввода-вывода, на которые следует обратить внимание?

Ответ или решение

Использование loop-устройства для обхода ошибки EBUSY на блочном устройстве, лежащем в основе device-mapper, является интересным вопросом, который требует тщательно обоснованного подхода. Прежде всего, давайте разберем теоретические аспекты, после чего перейдем к примерам и их применению.

Теория

Device-mapper — это подсистема ядра Linux, которая предоставляет гибкие возможности управления блочными устройствами, позволяя создавать настраиваемые устройства на основе существующих. Она позволяет, например, объединять несколько физических устройств в одно, изменять схему разделов диска и прочие манипуляции на уровне блочных устройств. Однако из-за его сложной структуры могут возникать ошибки, такие как EBUSY, если устройства уже используются в другой части системы.

EBUSY — это код ошибки, который в данном контексте сигнализирует о том, что операционная система не может захватить необходимый ресурс, поскольку он уже занят. Эту ошибку часто наблюдают при попытке выполнения операций над устройствами, которые находятся в активном использовании, например, корневая файловая система Linux.

Пример

В вашем случае вы сталкиваетесь с задачей включить начало блочного устройства (зону GPT) в маппинг device-mapper для использования с виртуальной машиной Windows 10. Однако доступ к тому же блочному устройству уже используют разделы Linux, что вызывает EBUSY. В интернете вы нашли решение с использованием loop-устройства, которое создает виртуальную копию блочного устройства и таким образом позволяет обойти ограничения, вызванные EBUSY.

Пример с использованием устройства loop показал, что данная техника позволяет успешно создать маппинг без ошибки. Преимущество loop-устройства заключается в том, что оно создает абстракцию поверх существующего блочного устройства, позволяя выполнять операции, которые в противном случае были бы заблокированы из-за активного использования устройства.

Применение

Теперь перейдем к практическому применению и оценке безопасности предложенного решения. Использование loop-устройства имеет свои плюсы и минусы.

Плюсы:

Изолирование Контекста: Loop-устройство позволяет изолировать изменяемый контекст от основного устройства, уменьшая риск конфликтов.
Гибкость: Возможность создания независимых маппингов на базе исходного устройства без физического вмешательства.
Виртуализация: Простота интеграции с виртуальными машинами без необходимости изменений на уровне оборудования.

Минусы:

Потенциальная Уязвимость: Даже если loop-устройство позволяет обойти EBUSY, оно не решает коренную проблему одновременного доступа. Если разделы изменяются параллельно, это все еще может привести к повреждению данных.
Усложненная Администрация: Дополнительные шаги, такие как создание и удаление loop-устройства, могут затруднить управление системой.
Производительность: Работа через промежуточный слой (как loop-устройство) может в некоторых случаях немного снизить производительность.

Следует отметить, что, хотя обход ошибки через loop-устройство может временно устранить проблему, важно понимать, насколько критично ваше приложение к параллельному доступу к данным. В случае с системой, включающей несколько операционных систем, всегда существует риск повреждения данных, особенно если обе системы могут потенциально изменять одни и те же данные.

Заключение

Рекомендую оценить преимущества и риски выбранного вами метода в контексте ваших рабочих процессов. Если вам важно предотвратить абсолютные повреждения данных, возможно, стоит рассмотреть альтернативы, такие как более сложные конфигурации device-mapper или даже использование программного обеспечения, специализирующегося на управлении многопользовательскими блочными устройствами.

Возможно, более безопасным вариантом будет создание DM-устройства, как предложено альтернативой, которое будет отображать только необходимые для Windows разделы, минимизируя риск ошибок в результате параллельного доступа. Такой метод позволит аккуратно разделить управление разделами между различными системами, обеспечивая более высокий уровень безопасности и контроля над данными.