Я пытаюсь создать зашифрованную файловую систему растущего по мере необходимости в Linux. Я знаком с LUKS и cryptsetup.
Я могу создать пустой файл:
fallocate -l 512M /root/image
Я могу создать контейнер LUKS на нем:
cryptsetup -y luksFormat /root/image
А потом «открой» это:
cryptsetup luksOpen /root/image luksvolume
На этом этапе я могу просто создать файловую систему:
mkfs.ext4 -j /dev/mapper/luksvolume
Это все прекрасно и денди. Тем не менее, это не относится к части «растут по требованию».
Идея состоит в том, что копирование файла 2 Гб в зашифрованной файловой системе «расширит» изображение так, чтобы оно стало достаточно большим для размещения файла.
Это вообще возможно сделать?
Ответы:
Да! Похоже, это возможно. Давайте проверим, как это может быть достигнуто. Обратите внимание, что это не создает истинную файловую систему роста по требованию, так как, когда файловая система достигает максимального размера разреженного файла, она сообщит об ошибках «нехватки места», если все еще нужно будет записать больше данных.
Первоначально я исследовал Thin Provisioning , широко известную технологию для экономии места в сценариях виртуализации. К сожалению, в обычных случаях использования Linux он доступен только с LVM . Поскольку это кажется немного за рамками вашего вопроса, я искал что-то еще.
Вторая концепция, которую я исследовал, это Sparse File . Это точно подходит для вашего вопроса и ... мое первоначальное сомнение было: « Хорошо. Я могу создать разреженный файл. Но что произойдет, когда я инициализирую его как контейнер LUKS? Будет ли такая инициализация распределять все доступное пространство? Если нет, что произойдет, когда я инициализирую файловую систему в таком контейнере? Будет ли
mkfs.ext4
выделено все доступное пространство? ". Поскольку у меня не было ответа, я решил попробовать. Итак, посмотрим, что случилось.Начнем с моей текущей системы, где у меня всего 3,3 ГБ свободного места в
/repository
файловой системе:Давайте создадим 10G sparse-файл в такой файловой системе:
и давайте проверим это ... это действительно редкий файл:
ОК. Итак, у нас есть файл 10G в файловой системе, в которой ранее было 3,3 ГБ свободного места. Сколько еще свободного места у меня есть?
Все еще 3.3G. Приятно. Sparse-файл действительно ... sparse-file ;-) Давайте сделаем шаг вперед, создав контейнер LUKS в таком файле 10G и ... посмотрим, не исчерпаем ли мы пространство:
Итак, теперь у меня есть открытый
secrets
контейнер, определенный поверх моего разреженного 10G-файла, хранящегося в файловой системе, имеющей только 3,3G свободного пространства.Сколько еще свободного места у меня есть?
Замечательный! Все еще 3.3ГБ. Наш зашифрованный контейнер практически не требует места!
Давайте проверим, все ли в порядке или есть что-то странное с нашей настройкой:
Кажется, все в порядке, поэтому давайте начнем использовать такой контейнер для хранения чего-либо. Давайте начнем с создания внутри нее файловой системы EXT4:
Похоже, это сработало, так как не было следа «из космоса». Давайте проверим:
Хм .... так что-то случилось. Мы потеряли что - то вроде 100M пространства , но .... это ожидаемое поведение: создание файловой системы ext4 DO требует написания большого количества метаданных. Так что это нормально, что некоторое пространство было использовано в процессе создания.
Это «рабочая» файловая система EXT4?
Да! Выглядит хорошо
Итак, теперь у нас есть файловая система EXT4, написанная внутри открытого контейнера LUKS, определенного поверх разреженного 10G-файла, хранящегося в файловой системе 3.3G.
Посмотрим, все ли работает правильно, выделив место «по требованию».
Давайте начнем с записи фиктивных данных в 500M в зашифрованную FS
Успели ли мы в создании файла?
Это выглядит так.
Что случилось с нашей настоящей файловой системой?
СХ! Мы «потеряли» чуть больше 500М. Это хорошо, кстати, так как физическое пространство действительно выделено по требованию!
Давайте сохраним еще 2 ГБ файла:
Что произошло?
Действительно мило. Что произойдет, если мы удалим файл?
Как и ожидалось, с sparse-файлом поведение точно такое же, как и при тонком обеспечении: после выделения пространство памяти не может быть востребовано при удалении файла. Но в целом это нормально. Не так ли?
Поэтому на данный момент ответ на ваш вопрос должен быть полным. Правильно?
Дополнение:
Посмотрим, что произойдет, когда подчеркнутое хранилище заполнится:
Какие? похоже, это удалось! Как это было возможно? Давайте проверим!
Хм ... выглядит хорошо. Мы уверены?
у нас кончилось пространство! Безо всяких ошибок!
Даже если было бы неплохо выяснить, что на самом деле произошло ... Я оставлю это на ваше усмотрение и / или навыки устранения неполадок других участников ServerFault ;-)
Веселиться!
Кстати, я проверил все вышеперечисленное, здесь:
источник
rsync
есть--sparse
опция, которая должна создавать разреженные файлы на целевом диске.