В нашей инфраструктуре виртуальных машин у нас есть кластерные узлы, подключенные к SAN.
Я пытаюсь выяснить, сколько «пустого пространства» остается при удалении файлов на наших серверах Redhat. На нашем сервере Windows мы используем sdelete, и это решает эту проблему, однако с Linux мне трудно найти решение.
Я определяю «белое пространство» как секторы? оставшиеся, которые не обнуляются, что SSD-диски должны сначала обнулить, прежде чем они смогут записывать на них.
Я отмечу одну вещь: что касается Linux, я знаю достаточно, чтобы быть опасным, но я не суперпользователь.
Просмотр дисков и разделов:
[root@rhserver1-DATA10 /]# fdisk -l
Disk /dev/sda: 53.7 GB, 53687091200 bytes, 104857600 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
Disk label type: dos
Disk identifier: 0x0005d52e
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 104857599 51915776 8e Linux LVM
Disk /dev/sdb: 53.7 GB, 53687091200 bytes, 104857600 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
Disk /dev/mapper/rhel_rhserver1--data10-root: 51.0 GB, 50964987904 bytes, 99540992 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
Disk /dev/mapper/rhel_rhserver1--data10-swap: 2147 MB, 2147483648 bytes, 4194304 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
Теперь посмотрим на использование диска:
[root@rhserver1-DATA10 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rhel_rhserver1--data10-root 48G 6.1G 42G 13% /
devtmpfs 906M 0 906M 0% /dev
tmpfs 921M 340K 920M 1% /dev/shm
tmpfs 921M 90M 831M 10% /run
tmpfs 921M 0 921M 0% /sys/fs/cgroup
/dev/sdb 50G 3.5G 44G 8% /ACMS01Backup
/dev/sda1 497M 210M 288M 43% /boot
tmpfs 185M 20K 185M 1% /run/user/1000
tmpfs 185M 0 185M 0% /run/user/1002
После многих часов поиска в Google я нашел это, думаю, это показывает мне, сколько «белого пространства» доступно для очистки.
[root@rhserver1-DATA10 /]# parted /dev/sda unit MB print free | grep 'Free Space' | tail -n1 | awk '{print $3}'
1.02MB
[root@rhserver1-DATA10 /]# parted /dev/sda unit '%' print free | grep 'Free Space' | tail -n1 | awk '{print $3}'
0.00%
Я считаю разумным выходом для раздела 497M.
Итак, теперь я хочу сделать то же самое только на моем смонтированном диске (я думаю, что он смонтирован).
parted /dev/mapper/rhel_rhserver1--data10-root unit MB print free | grep 'Free Space' | tail -n1 | awk '{print $3}'
parted /dev/mapper/rhel_rhserver1--data10-root unit '%' print free | grep 'Free Space' | tail -n1 | awk '{print $3}'
Что мне ничего не дает.
Мой / etc / fstab /:
[root@rhserver1-DATA10 /]# cat /etc/fstab
/dev/mapper/rhel_rhserver1--data10-root / xfs defaults 0 0
UUID=2f97a17c-a6d5-4904-ad5c-7c16b4510201 /boot xfs defaults 0 0
/dev/mapper/rhel_rhserver1--data10-swap swap swap defaults 0 0
/dev/disk/by-uuid/be4c45cf-5d72-4b97-b647-2e585947041f /ACMS01Backup auto nosuid,nodev,nofail,x-gvfs-show 0 0
Итак, мой вопрос: на правильном ли я пути?
Хорошо ли я объяснил, что ищу?
Есть ли термин для "белого пространства", который может помочь мне в поиске в Google?
Я обнаружил, что могу запустить "fstrim -v /" в корне, но мне очень хотелось бы знать, сколько там места.
Кроме того, я пытаюсь понять, что производственная система является интенсивной системой ввода-вывода fstrim, следует ли ее запускать в непиковые часы?
Есть ли вероятность потери данных при запуске "fstrim -v /"?
Я пытаюсь сделать то же самое пару недель назад и не знаю, как это сделать. Делюсь официальным заявлением на портале поддержки Redhat.
В настоящее время невозможно уменьшить размер раздела или логического тома с помощью файловой системы xfs. Если вас интересует эта функциональность, обратитесь в службу поддержки Red Hat, укажите Red Hat bugzilla 1062667 и укажите свой вариант использования для уменьшения / сжатия XFS. В качестве возможного обходного пути в некоторых средах тома LVM с тонким предоставлением можно рассматривать как дополнительный уровень ниже файловой системы XFS.
Удачи!!
Возможность запускать fstrim на разделах / была бы лучшим решением, однако с тем, как настроен ваш ESXi, это было бы невозможно.
У вас должна быть возможность включить сброс как на виртуальной машине, так и на устройстве хранения.
Попытка уменьшить размер раздела или логического тома с файловой системой xfs не может быть осуществлена. Это известная ошибка Fedora. Если вас интересует эта функциональность, обратитесь в службу поддержки Red Hat, укажите Red Hat bugzilla 1062667 и укажите свой вариант использования для уменьшения / сжатия XFS.
В качестве возможного решения проблемы в некоторых средах тома LVM с тонким предоставлением можно рассматривать как дополнительный уровень ниже файловой системы XFS.
Если виртуальные машины стремятся к расширенному предоставлению VMDK, это означает, что нечего возвращать, когда вы пытаетесь обрезать (технически говоря, SCSI UNMAP) свои тома.
Если внутреннее хранилище работает с тонкой подготовкой, вам также необходимо использовать файлы VMDK с отложенным обнулением, чтобы уменьшить объем хранилища и дать возможность серверной части кэшировать / удалять теплые данные.
Возможны два варианта:
Когда хранилище предоставляется удаленным сервером через сеть SAN, вы можете отбрасывать блоки только в том случае, если хранилище имеет тонкое предоставление.
dd if = / dev / zero of = BIGFILE bs = 1024000 rm -f BIGFILE
Насколько я могу судить, это делает то же самое, что и sdelete, однако может вызвать всплеск дискового ввода-вывода, а также потребовать времени для запуска.
Что-то попробовать на ночь
Любой вариант не лучший, но переформатировать каждую виртуальную машину для получения ext3 или ext4 не представляется возможным.
Что вы можете сделать, так это настроить правило привязки для всех виртуальных машин Linux и использовать вариант 1, указанный выше.