In unserer VM-Infrastruktur haben wir Hosts geclustert, die in ein SAN gehen.
Ich versuche herauszufinden, wie viel "weißer Raum" beim Löschen von Dateien auf unseren Redhat-Servern übrig bleibt. Auf unserem Windows-Server verwenden wir sdelete und das behebt das Problem, aber unter Linux habe ich Mühe, eine Lösung zu finden.
Ich definiere "Leerraum" als die Sektoren? Übrig geblieben sind nicht Nullen, die SSD-Laufwerke erst Nullen müssen, bevor sie darauf schreiben können.
Eine Sache, auf die ich hinweisen werde, ist, wenn es um Linux geht, dass ich genug weiß, um gefährlich zu sein, aber kein Superuser bin.
Durchsuchen der Laufwerke und Partitionen:
[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
Betrachten Sie nun die Datenträgerverwendung:
[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
Nachdem ich viele Stunden gegoogelt habe, habe ich festgestellt, dass es mir zeigt, wie viel "weißer Raum" verfügbar ist, um aufgeräumt zu werden.
[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%
Ich denke, eine vernünftige Ausgabe für eine 497M-Partition.
Jetzt möchte ich dasselbe nur auf meinem gemounteten Laufwerk tun (ich denke, es ist gemountet.)
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}'
Was gibst mir nichts.
Meine / 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
Also meine Frage ist, bin ich auf dem richtigen Weg?
Habe ich erklärt, wonach ich suche?
Gibt es einen Begriff für "Leerraum", der mir beim Googeln helfen könnte?
Ich habe festgestellt, dass ich "fstrim -v /" auf der Wurzel ausführen kann, aber ich möchte wirklich wissen, wie viel Platz dort ist.
Ich versuche auch herauszufinden, dass das Produktionssystem sehr intensiv ist, sollte es außerhalb der Hauptverkehrszeiten laufen?
Besteht die Möglichkeit eines Datenverlusts mit "fstrim -v /"?
quelle
discardMount-Option für die Dateisysteme festlegen .blkidSie, das Programm auszuführen, und prüfen Sie, ob Sie die UUID abrufen und denpartedBefehl erneut ausführen können .Antworten:
Die beste Lösung wäre es, fstrim auf den / -Partitionen auszuführen. Mit der Konfiguration Ihres ESXi wäre dies jedoch nicht möglich.
Sie müssen in der Lage sein, Discards sowohl auf der VM als auch auf dem Speichergerät zu aktivieren.
Der Versuch, eine Partition oder ein logisches Volume mit dem Dateisystem xfs auf die Größe zu verkleinern, ist nicht möglich. Dies ist ein bekannter Fehler bei Fedora. Wenn Sie an dieser Funktion interessiert sind, wenden Sie sich an den Red Hat-Support und die Referenznummer Red Hat Bugzilla 1062667 und geben Sie Ihren Anwendungsfall an, bei dem eine XFS-Reduzierung / Verkleinerung erforderlich ist.
In einigen Umgebungen können Thin Provisioning-LVM-Volumes als zusätzliche Ebene unter dem XFS-Dateisystem angesehen werden.
Wenn es sich bei den VMs um Thick-Provisioning-VMDKs handelt, müssen Sie beim Versuch, die Volumes zu kürzen (technisch gesehen: SCSI UNMAP), nichts zurückfordern.
Wenn auf dem Back-End-Speicher Thin Provisioning ausgeführt wird, müssen Sie auch VMDK-Dateien mit verzögerter Nullung verwenden, um den Speicher zu verkleinern und dem Back-End das Zwischenspeichern / Deduplizieren der warmen Daten zu ermöglichen.
Zwei mögliche Optionen:
Wenn der Speicher von einem Remoteserver in einem SAN bereitgestellt wird, können Sie Blöcke nur dann verwerfen, wenn der Speicher mit Thin Provisioning ausgestattet ist.
dd if = / dev / zero von = BIGFILE bs = 1024000 rm -f BIGFILE
Soweit ich das beurteilen kann, hat dies die gleiche Wirkung wie sdelete, kann jedoch zu einem Anstieg der Festplatten-E / A führen und es kann eine Weile dauern, bis sie ausgeführt wird.
Etwas über Nacht zu versuchen
Beide Optionen sind nicht die besten, aber das Neuformatieren jeder VM, um ext3 oder ext4 zu erhalten, klingt nicht machbar.
Möglicherweise können Sie eine Affinitätsregel für alle Linux-VMs einrichten und Option 1 von oben verwenden.
quelle
Ich versuche vor ein paar Wochen dasselbe zu tun und ich finde nicht, wie ich es tun soll. Ich teile die offizielle Erklärung im Redhat-Supportportal.
Es ist derzeit nicht möglich, die Größe einer Partition oder eines logischen Volumes mit dem Dateisystem xfs zu reduzieren. Wenn Sie an dieser Funktion interessiert sind, wenden Sie sich an den Red Hat-Support und die Referenznummer Red Hat Bugzilla 1062667 und geben Sie Ihren Anwendungsfall an, bei dem eine XFS-Reduzierung / Verkleinerung erforderlich ist. Als mögliche Problemumgehung in einigen Umgebungen können Thin Provisioning-LVM-Volumes als zusätzliche Ebene unter dem XFS-Dateisystem betrachtet werden.
Viel Glück!!
quelle