Я создал разреженный файл filesystem.img, отформатированный с помощью cryptsetup luksFormat, создал на нем файловую систему btrfs. Использование диска с файлом образа отлично расширяется при добавлении файлов в файловую систему btrfs. Однако удаление файла на нем, конечно, не уменьшает использование разреженного файлового диска, поэтому мне нужно решение, чтобы сделать это вручную.
К сожалению fstrim не работает, говорят the discard operation is not supported.
Я не могу просто записывать нули с помощью 'dd' или 'freezero' в файл файловой системы, поскольку зашифрованные нули не являются нулями, и это приведет к увеличению, а не к уменьшению размера изображения.
Я, вероятно, мог бы изменить размер файловой системы до минимального размера, а затем усечь файл изображения до размера файловой системы + размера смещения luks, но я обнаружил, что btrfs очень неудобен для сжатия, в настоящее время btrfs filesystem usageсообщает ~ 23 ГБ бесплатно и ~ 81 ГБ, но я не могу уменьшить его дальше, поэтому у меня ~ 28% перерасхода.
'btrfs balance', вероятно, поможет, но похоже, что он может работать даже дольше, чем повторное копирование всех данных в новое изображение.
Последнее, конечно, решение, но не очень хорошее. И не всегда удается создать новый образ диска необходимого места.
Я попытался выяснить, как выглядят «декодированные нули», создав одно и то же изображение с нулевым пустым кодом, зашифрованное с помощью парольной фразы, но каждый из 512-байтовых блоков (размер, сообщаемый статусом cryptosetup) отличается. Похоже, что luks не шифруют каждый блок одним и тем же ключом.
Есть еще идеи?
UPD. То, что я еще пробовал залить btrfs нулевым файлом, нахожу смещения:
# filefrag -b4K -ves zero
Filesystem type is: 9123683e
File size of zero is 34811904 (8499 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 3477: 17664.. 21141: 3478:
1: 3478.. 4732: 3399.. 4653: 1255: 21142:
2: 4733.. 5673: 11673.. 12613: 941: 4654:
3: 5674.. 6379: 16400.. 17105: 706: 12614:
4: 6380.. 6908: 4654.. 5182: 529: 17106:
5: 6909.. 7305: 12614.. 13010: 397: 5183:
6: 7306.. 7823: 15770.. 16287: 518: 13011:
7: 7824.. 8220: 17106.. 17502: 397: 16288:
8: 8221.. 8338: 5183.. 5300: 118: 17503:
9: 8339.. 8418: 13011.. 13090: 80: 5301:
10: 8419.. 8477: 17503.. 17561: 59: 13091:
11: 8478.. 8489: 13091.. 13102: 12: 17562:
12: 8490.. 8493: 13564.. 13567: 4: 13103:
13: 8494.. 8496: 3328.. 3330: 3: 13568:
14: 8497.. 8498: 13103.. 13104: 2: 3331: last,eof
сохранить его в другой файл файловой системы zero.frag и попробуйте заполнить "физические" блоки файла изображения нулями:
# offset=4096
# cat zero.frag | tail -n +4 | head -n -1 | while read rec
do seek=${rec#*:*:}; seek=${seek%%.*}; seek=$((seek+offset))
count=${rec#*:*:*: }; count=${count%%:*}; count="${count#"${count%%[![:space:]]*}"}"
dd if=/dev/zero bs=4096 seek=$seek count=$count of=filesystem.img
done
но это разрушило файловую систему. Его можно было смонтировать, но существующие файлы были неверными. Кроме того, использование диска "filesystem.img" стало даже меньше, чем использованное пространство файловой системой btrfs. Так что все еще не решено.
Проблема здесь в том, что вы использовали необработанный файл образа диска для хранения файловой системы. Это сильно ограничивает средства, с помощью которых вы можете снова сделать этот файл разреженным.
Инструмент virt-sparsify может сделать файл разреженным, но требует, чтобы он не использовался, поэтому вам придется выключить виртуальную машину, которая использует образ, перед запуском virt-sparsify в теме.
В будущем, если вам нужно отбросить блоки в сети, используйте хранилище резервных копий, которое поддерживает это, например образы qcow2 или блочные устройства с тонким выделением ресурсов ZFS, btrfs или LVM.