☰

TRIM/UNMAP Zvol über iSCSI

tag-icon • tag-icon zfsonlinux open-iscsi
TRIM/UNMAP Zvol über iSCSI

Ich richte gerade ein SAN für den diskless Boot ein. Mein Backend besteht aus einem über iSCSI freigegebenen ZFS-Vol. Bis jetzt funktioniert alles einwandfrei, außer TRIM/UNMAP. Zu Testzwecken habe ich zwei VMs mit Ubuntu20.04 in VirtualBox eingerichtet, die über ein internes Netzwerk mit statischen IPv4-Adressen miteinander vernetzt sind. Auf dem Ziel (tgt) habe ich ein zweites virtuelles Laufwerk, das mit ZFS formatiert ist. Auf diesem Zpool habe ich ein ZVol erstellt und es mit GPT und ext4 formatiert.

/etc/tgt/conf.d/iscsi.conf
<target example.com:lun1>
    <backing-store /dev/zvol/tank/iscsi_share>
        params thin_provisioning=1
    </backing-store>
    initiator-address 192.168.0.2
</target>

Auf dem Initiator (open-iscsi) verwende ich diesen Befehl, um einen TRIM-Vorgang auszulösen:

sudo mount /dev/sdb1 /iscsi-share
sudo dd if=/dev/zero of=/iscsi-share/zero bs=1M count=512
sudo rm /iscsi-share/zero
sudo fstrim /iscsi-share

aber die Shell antwortet mit „fstrim: /iscsi-share: die Discard-Option wird nicht unterstützt“. Wenn ich diese Befehle auf der Zielmaschine ausführe, verringert sich die „REFER“-Eigenschaft des zVol wie erwartet.

Da ich bei meiner Suche im Internet nichts gefunden habe, konnte ich auch keinen Hinweis darauf finden, warum dies nicht funktioniert oder ob dies überhaupt möglich ist.

Edit: Da mir geraten wurde, die Option zu nutzenThin_Provisioning.

Nachdem ich das Laufwerk neu partitioniert und auf dem Initiator gemountet hatte, erhielt ich eine Fehlermeldung blk_update_request: critical target error, dev sdb, sector 23784 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0 für mehrere Sektoren und nach dem Erstellen und Löschen meiner Testdatei fstrimschickte ich die Meldung

blk_update_request: I/O error, dev sdb, sector 68968 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
fstrim: iscsi-share: FITRIM ioctl failed: Input/output error

Edit: Da es Antworten gab, die sich aufLIOIch habe jetzt auch targetcli ausprobiert. Dort habe ich mit meinem zVol unter /backstores/block/iscsi ein Ziel eingerichtet und set attribute emultate_tpu=1. Nachdem ich dies in meinen Initiator importiert hatte, habe ich es neu partitioniert, formatiert und auf dem Initiator gemountet. Dann habe ich meine Testdatei erstellt, sie gelöscht und den fstrimBefehl ausgeführt und es hat funktioniert. Danke für die Hilfe.

Antwort1

LIO deaktiviert UNMAP standardmäßig. Wenn Sie es aktivieren möchten, sollten Sie das emulate_tpuAttribut auf dem Ziel festlegen.

Antwort2

Ihre Frage ist sehr spezifisch für die iSCSI-Zielimplementierung. Die meisten von ihnen führen keine 1:1-SCSI-Befehlszuordnung durch. Wenn das iSCSI-Ziel also eine Festplatte emuliert, werden nicht erkannte Befehle (einschließlich UNMAP natürlich) nicht an den zugrunde liegenden Speicher @ Back-End umgeleitet, ES SEI DENN, Sie fordern das iSCSI-Ziel ausdrücklich dazu auf. Mit TGT meinen Sie, dass Sie in der Konfigurationsdatei „thin_provisioning=1“ für Ihre virtuelle LUN angeben.

Antwort3

TRIM ist in Ubuntu 20.04 standardmäßig so aktiviert, dass es wöchentlich ausgeführt wird. Daher sollte es auch bei manueller Ausführung kein Problem geben. Sie können dies vorsichtshalber in fstrim.service und fstrim.timer überprüfen:https://askubuntu.com/questions/1034169/ist-trim-auf-meiner-ubuntu-18-04-installation-aktiviert

Allerdings sieht es tatsächlich so aus, als müssten Sie UNMAP auf dem Ziel aktivieren, wie bereits erwähnt. Da viele SATA-SSDs Probleme mit UNMAP hatten, wurde es in LIO standardmäßig deaktiviert:http://www.linux-iscsi.org/Doc/LIO%20Admin%20Manual.pdf.

Nebenbei bemerkt wird es natürlich viel einfacher, wenn ein iSCSI-Ziel TRIM/UNMAP nativ und ohne weitere Anpassungen unterstützt. Hier ist ein Beispiel:https://forums.starwindsoftware.com/viewtopic.php?f=5&t=5343

verwandte Informationen