Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung Nächste Überarbeitung | Vorherige Überarbeitung Nächste Überarbeitung Beide Seiten, nächste Überarbeitung | ||
admin_grundlagen:ssd [2019/01/01 22:47] ingo_wichmann |
admin_grundlagen:ssd [2021/12/30 08:20] ingo_wichmann [andere Blockgeräte die discard unterstützen] |
||
---|---|---|---|
Zeile 4: | Zeile 4: | ||
Geräte mit 1 in der Spalte "ROTA" liegen auf rotierenden Geräten, Geräte mit 0 nicht. | Geräte mit 1 in der Spalte "ROTA" liegen auf rotierenden Geräten, Geräte mit 0 nicht. | ||
- | ====== Daten auf einer Partition oder SSD löschen & TRIM auslösen ====== | + | ===== alle Blockgeräte die discard unterstützen ===== |
+ | z.B. virtio (( | ||
+ | <file xml> | ||
+ | <disk type="file" device="disk"> | ||
+ | <driver name="qemu" type="qcow2" discard="unmap"/> | ||
+ | <target dev="vda" bus="virtio"/> | ||
+ | </file> | ||
+ | )) | ||
+ | lsblk -bo NAME,DISC-MAX | ||
+ | grep -vxl 0 /sys/block/*/queue/discard_max_hw_bytes | sed -r 's:/sys/block/(.*)/queue/discard_max_hw_bytes:/dev/\1:' | ||
+ | (( | ||
+ | "__A discard_max_hw_bytes value of 0 means that the device does not support discard functionality.__" | ||
+ | https://www.kernel.org/doc/html/latest/block/queue-sysfs.html#discard-max-bytes-rw | ||
+ | )) | ||
+ | ====== Ganzen Inhalt einer Partition oder SSD löschen & TRIM auslösen ====== | ||
((Optional (damit man es besser sieht) Einsen auf die Partition schreiben: | ((Optional (damit man es besser sieht) Einsen auf die Partition schreiben: | ||
tr '\0' '\377' < /dev/zero | dd of=/dev/sda2 bs=1MiB status=progress | tr '\0' '\377' < /dev/zero | dd of=/dev/sda2 bs=1MiB status=progress | ||
Zeile 86: | Zeile 100: | ||
====== kontinuierlich freie Bereiche eines Dateisystems "trimmen" ====== | ====== kontinuierlich freie Bereiche eines Dateisystems "trimmen" ====== | ||
- | TODO: verlangsamt laut diversen Webseiten die Geschwindikeit in der Dateien gelöscht werden, da nach dem Löschen jeder Datei die SSD informiert wird -> prüfen | + | TODO: verlangsamt laut diversen Webseiten die Geschwindigkeit in der Dateien gelöscht werden, da nach dem Löschen jeder Datei die SSD informiert wird -> prüfen |
mount -o discard /dev/sda2 /mnt/ext4 | mount -o discard /dev/sda2 /mnt/ext4 | ||
Zeile 108: | Zeile 122: | ||
-> sollte lauter Einsen ausgeben | -> sollte lauter Einsen ausgeben | ||
rm file1 | rm file1 | ||
+ | sync | ||
Prüfen: | Prüfen: | ||
watch hdparm --read-sector 14874624 /dev/sda | watch hdparm --read-sector 14874624 /dev/sda | ||
-> sollte (spätestens nach ein paar Minuten) lauter Nullen ausgeben)) | -> sollte (spätestens nach ein paar Minuten) lauter Nullen ausgeben)) | ||
+ | |||
+ | ====== kontinuierlich freie Bereiche im LVM "trimmen" ====== | ||
+ | Beim Löschen und verkleinern von Logical Volumes frei werdende Bereiche "trimmen": (( | ||
+ | warum ist das nicht default? | ||
+ | |||
+ | Aus https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717313 : | ||
+ | "Even with the automatic backups of the lvm metadata, it is impossible to recover from the wrongly removed LV. This is the reason why this feature is off by default." und "The discards commands will also be issued when shrinking or moving a LV to an other PV, if something is going wrong during these operations, the data will be lost. So it's not only when explicitly removing an LV." | ||
+ | |||
+ | Alternative: so ähnlich wie man regelmäßig fstrim aufruft, kann man die leeren Blöcke einer Volume Group behandeln: | ||
+ | |||
+ | <file txt /etc/systemd/system/fstrim.service.d/vg.conf> | ||
+ | [Service] | ||
+ | ExecStart=lvcreate -l100%FREE -n trim your_volume_group | ||
+ | ExecStart=blkdiscard /dev/your_volume_group/trim | ||
+ | ExecStart=lvremove your_volume_group/trim | ||
+ | </file> | ||
+ | )) | ||
+ | <file txt /etc/lvm/lvm.conf> | ||
+ | … | ||
+ | devices { | ||
+ | … | ||
+ | issue_discards = 1 | ||
+ | … | ||
+ | } | ||
+ | </file> | ||
+ |