df
и ls
сообщать о разных размерах на моем хост-компьютере из-за разницы между выделенным размером и объемом пространства, которое фактически используется в файловой системе EXT4. Проблема в том, что оба сообщают неправильный размер. qemu-img
также не сообщает фактическое пространство, используемое в файловой системе гостя (также EXT4).
На хосте:
# qemu-img info sdb.raw
image: sdb.raw
file format: raw
virtual size: 2.0T (2173253451776 bytes)
disk size: 1.9T
# ls -larth sdb.raw
-rw-r--r-- 1 hypervisor hypervisor 2.0T Mar 6 13:47 sdb.raw
# du -sh sdb.raw
1.9T sdb.raw
# fdisk -l sdb.raw
Disk sdb.raw: 2 TiB, 2173253451776 bytes, 4244635648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E6242A7E-1253-E74A-9389-68654A21E4F4
Device Start End Sectors Size Type
sdb.raw1 2048 4244635614 4244633567 2T Linux filesystem
На гостевой (/ dev / vdb1):
# df -h
Filesystem Size Used Avail Use% Mounted on
dev 32G 0 32G 0% /dev
run 32G 496K 32G 1% /run
/dev/vda2 220G 100G 111G 48% /
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 32G 0 32G 0% /sys/fs/cgroup
tmpfs 32G 26M 32G 1% /tmp
/dev/vdb1 2.0T 761G 1.2T 41% /root
tmpfs 6.3G 0 6.3G 0% /run/user/1002
Как видите, я использую только 761G в гостевой системе, и еще доступно 1,2T. Несмотря на это, qemu-img
говорит, что использую 1.9T. В чем причина? Есть способ исправить это? Я хотел бы увидеть фактическое используемое пространство на хост-машине. Я знаю, что это возможно, потому что он работал правильно до того, как я заполнил sdb.raw
с данными - qemu сообщил правильный размер диска, основанный на пространстве, используемом внутри диска. К сожалению, сработало только одно - когда постепенно увеличивалась занимаемая площадь. После того, как я удалил некоторые файлы и уменьшил используемое пространство с 1,9 ТБ до 761 ГБ, размер, указанный в qemu-img
на меньшее значение не изменилось, осталось 1,9T.
qemu-img
и du
оба сообщают фактическое выделенное пространство с точки зрения хозяина. Они не могут знать / понять, действительно ли гостевая ОС использует это пространство или, как в вашем случае, оно было освобождено пользователем.
Чтобы сообщить хозяину, что у вашего гостя много свободного места, вам необходимо fstrim
ваша гостевая файловая система и вы должны быть уверены, что стек вашего qemu / гостевого блочного устройства правильно передается вниз TRIM/discard
Запросы. Для этого вам необходимо:
используйте драйвер блочного устройства qemu с поддержкой TRIM / discard. Примеры таких приводов: virtio-scsi
, scsi
и sata/ahci
. Все эти драйверы выставляют блочные устройства с помощью классического /dev/sd[abcd...]
номенклатура. С другой стороны, похоже, что ваш гость использует простой virtio
водитель (с /dev/vd[abcd...]
имена), что делает не поддержка TRIM / Discard. Вы можете проверить, не поддерживает ли ваш драйвер поддержку, выполнив lsblk -D
;
включить относительный домен libvirt discard=unmap
вариант;
Наконец, ваш хост должен использовать файловую систему с hole_punching
поддерживает как ext4 (который вы используете), так и xfs.
Ты можешь читать Вот для получения дополнительной информации.
Если все предпосылки верны, выдача fstrim <mount_point>
внутри вашего гостя также автоматически освободит неиспользуемое пространство на хосте. Обязательно поймите, что логический / кажущийся размер файла останется неизменным (то есть: он будет показывать 2,0 ТБ после fstrim
), но используя qemu-img
или du
покажет истинный (меньший) размер выделенного файла.
Если предварительные условия не выполнены, вам необходимо автономно сжать файл изображения с помощью virt-sparsify
или qemu-img convert
после очистки гостевого свободного места нулями (например: dd if=/dev/zero of=bigfile bs=1M count=<almost_all_free_space>; rm bigfile
).
Убедитесь, что вы понимаете, что означают вышеуказанные шаги: любая ошибка может безвозвратно повредить ваш файл изображения. И убедитесь, что у вас есть надежная резервная копия, прежде чем пытаться выполнять какие-либо операции с файлом образа диска! *
Это ожидаемое поведение. Как вы писали, «после того, как я удалил некоторые файлы и уменьшил используемое пространство с 1.9T до 761G» - необработанный виртуальный образ не может «собирать мусор» автоматически, и реальное пространство останется записанным и выделенным даже для удаленных файлов. Обходной путь - выполнить (двойное) преобразование raw> qcow2 (> raw).
Более подробно объяснено здесь - https://balau82.wordpress.com/2011/05/08/qemu-raw-images-real-size/ и тут - https://techpiezo.com/tech-insights/raw-vs-qcow2-disk-images-in-qemu-kvm/