Come ottenere spazio libero dall'unità montata Redhat 7


14

Nella nostra infrastruttura VM, abbiamo cluster host che vanno a una SAN.

Quello che sto cercando di capire è quanto "spazio bianco" è rimasto quando si eliminano i file all'interno dei nostri server Redhat. Sul nostro server Windows utilizziamo sdelete e questo risolve il problema, tuttavia con Linux faccio fatica a trovare una soluzione.

Sto definendo "spazio bianco" come settori? che non vengono azzerati, le unità SSD devono prima azzerarsi prima di poter scrivere su di essa.

Una cosa che sottolineo è che quando si tratta di Linux ne so abbastanza per essere pericoloso ma non sono un super utente.

Esaminando le unità e le partizioni:

[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

Ora guardando l'utilizzo del disco:

[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

Dopo molte ore di ricerche su google ho trovato questo, penso che mi stia mostrando quanto "spazio bianco" è disponibile per essere ripulito.

[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%

Penso che un output ragionevole per una partizione 497M.

Quindi ora voglio fare la stessa cosa solo sul mio disco montato (penso che sia montato).

 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}'

Che non mi dà niente.

Il mio / 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

Quindi la mia domanda è: sono sulla strada giusta?

Ho spiegato bene cosa sto cercando?

Esiste un termine per "spazio bianco" che potrebbe aiutare il mio googling?

Ho scoperto che posso eseguire "fstrim -v /" sul root ma mi piacerebbe davvero sapere quanto spazio c'è.

Inoltre sto cercando di capire che queste tesi sono che il sistema di produzione è intensivo per I / O, dovrebbe essere eseguito nelle ore di punta?

Qualche possibilità di perdita di dati con "fstrim -v /"?


Puoi anche impostare l' discardopzione mount sul filesystem.
Michael Hampton

Forse usando l'UUID dell'unità montata anziché / dev / mapper? Prova a eseguire blkide vedi se riesci a ottenere l'UUID e riesegui il partedcomando.
Wilson,

Risposte:


12

Essere in grado di eseguire fstrim su / partitions sarebbe la soluzione migliore, tuttavia con il modo in cui ESXi è configurato non sarebbe possibile.

Devi essere in grado di abilitare gli scarti sia sulla macchina virtuale che sul dispositivo di archiviazione.

Cercare di ridurre le dimensioni di una partizione o di un volume logico con il filesystem xfs non può essere fatto, questo è un bug noto con fedora. Se sei interessato a questa funzionalità, contatta il supporto Red Hat e fai riferimento a Red Hat bugzilla 1062667 e fornisci il tuo caso d'uso per la necessità di riduzione / riduzione XFS.

Come possibile soluzione in alcuni ambienti, i volumi LVM con thin provisioning possono essere considerati come un livello aggiuntivo sotto il file system XFS.

Se le macchine virtuali sono VMDK con provisioning di grandi dimensioni, il che significa che non c'è nulla da recuperare quando si tenta di tagliare (tecnicamente parlando; SCSI UNMAP) i volumi.

Se l'archiviazione back-end esegue il thin provisioning, è necessario utilizzare anche file VMDK azzerati in modo pigro per ridurre l'archiviazione e consentire al back-end di memorizzare nella cache / deduplicare i dati caldi.

Due possibili opzioni:

  1. Quando l'archiviazione è fornita da un server remoto attraverso una SAN, è possibile scartare i blocchi solo se l'archiviazione è thin provisioning.

    1. VMotion tutte le macchine virtuali in un diverso archivio dati e utilizzare gli strumenti VMWare integrati
    2. Connettersi all'host ESXi con SSH
    3. Passare alla cartella della macchina virtuale
    4. Verifica l'utilizzo del disco con du
    5. Esegui vmkfstools -K [disco]
    6. Verifica l'utilizzo del disco con du
  2. dd if = / dev / zero of = BIGFILE bs = 1024000 rm -f BIGFILE

Da quello che posso dire questo fa la stessa cosa di sdelete, tuttavia può causare un picco nell'I / O del disco e richiedere del tempo per l'esecuzione.

Qualcosa da provare durante la notte

Entrambe le opzioni non sono le migliori ma riformattare ogni VM per ottenere ext3 o ext4 non sembra fattibile.

Quello che potresti essere in grado di fare è impostare una regola di affinità per tutte le macchine virtuali Linux e utilizzare l'opzione 1 dall'alto.


12

Cerco di fare la stessa cosa un paio di settimane fa e non trovo come. Condivido la dichiarazione ufficiale sul portale di supporto di Redhat.

Al momento non è possibile ridurre le dimensioni di una partizione o di un volume logico con il filesystem xfs. Se sei interessato a questa funzionalità, contatta il supporto Red Hat e fai riferimento a Red Hat bugzilla 1062667 e fornisci il tuo caso d'uso per la necessità di riduzione / riduzione XFS. Come possibile soluzione alternativa in alcuni ambienti, i volumi LVM con thin provisioning possono essere considerati come un livello aggiuntivo sotto il file system XFS.

In bocca al lupo!!


Grazie per il commento, tuttavia, non sto cercando di ridurre la dimensione dello spazio disponibile sulla VM. Le unità SSD hanno un (errore), ovvero quando i dati vengono eliminati, il settore deve essere prima azzerato e quindi può essere scritto su vs se il settore non è mai stato scritto su di esso è già azzerato. Sto cercando di capire come in Windows con sdelete posso usare "fstrim -v /". Prima di iniziare, sto cercando di capire se posso vedere quanti settori saranno interessati e quale impatto avrebbe sul sistema.
Anthony Fornito,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.