Як отримати вільний простір з змонтованого накопичувача Redhat 7

У нашій інфраструктурі VM ми згрупували хостів, що йдуть до 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

Після багатьох годин гуглінгу я виявив це, я думаю, це показує мені, скільки "білого простору" є доступним для очищення.

[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

Тож моє запитання: чи я на вірному шляху?

Я пояснив, що я добре шукаю?

Чи є термін "білий простір", який може допомогти моєму гуглю?

Я виявив, що я можу запустити "fstrim -v /" на корені, але мені дуже хочеться знати, скільки місця там.

Крім того, я намагаюся з'ясувати, що тезами є виробнича система є fstrim I / O інтенсивним, чи слід працювати в не пікові години?

Будь-який шанс втрати даних під керуванням "fstrim -v /"?

Бути в змозі запустити fstrim на / розділах було б найкращим рішенням, однак при їх налаштуванні ESXi це було б неможливо.

Потрібно мати можливість увімкнути скидки як на VM, так і на запам'ятовуючий пристрій.

Спроба зменшити розмір розділу чи логічного об'єму з файловою системою xfs неможливо, це відома помилка з Fedora. Якщо вас зацікавила ця функціональність, зверніться до служби підтримки Red Hat та довідкової програми Red Hat bugzilla 1062667 та надайте свій приклад використання для зменшення / скорочення XFS.

Як можлива обробка в деяких середовищах, тонкі передбачені обсяги LVM можуть розглядатися як додатковий шар під файловою системою XFS.

Якщо VM не хочуть отримати товстий VMDK, це означає, що немає чого повертати, коли ви намагаєтеся обрізати (технічно кажучи; SCSI UNMAP) ваші обсяги.

Якщо резервне сховище працює з тонким резервуванням, вам також потрібно використовувати ліниві нульові файли VMDK, щоб зменшити обсяг пам’яті та зробити можливим для бекенда кешувати / виводити теплі дані.

Два можливі варіанти:

1. Коли зберігання надається віддаленим сервером через SAN, ви можете відкинути блоки лише в тому випадку, якщо сховище є тонким.

   1. Перемістіть всі VM в інший сховище даних та використовуйте вбудовані інструменти VMWare
   2. Підключіться до хоста ESXi за допомогою SSH
   3. Перейдіть до папки віртуальної машини
   4. Перевірте використання диска за допомогою du
   5. Запустити vmkfstools -K [диск]
   6. Перевірте використання диска за допомогою du

2. dd, якщо = / dev / zero = BIGFILE bs = 1024000 rm -f BIGFILE

З того, що я можу сказати, це робить те саме, що і sdelete, проте це може спричинити сплеск вводу / виводу диска, а також зайняти деякий час.

Щось спробувати протягом ночі

Будь-який варіант не найкращий, але переформатування кожного VM для отримання ext3 або ext4 не здається можливим.

Що ви можете зробити, це налаштувати правило афінності для всіх віртуальних машин Linux та використовувати варіант 1 зверху.

Я намагаюся зробити те ж саме пару тижнів тому, і не знаю, як це зробити. Я ділюсь офіційною заявою на порталі підтримки Redhat.

Наразі зменшити розмір розділу чи логічного обсягу за допомогою файлової системи xfs неможливо. Якщо вас зацікавила ця функціональність, зверніться до служби підтримки Red Hat та довідкової програми Red Hat bugzilla 1062667 та надайте свій приклад використання для зменшення / скорочення XFS. Як можливе вирішення в деяких середовищах, тонкі передбачені обсяги LVM можуть розглядатися як додатковий шар під файловою системою XFS.

Удачі!!