☰

RECORTAR/DESMAPAR Zvol sobre iSCSI

tag-icon • tag-icon zfsonlinux open-iscsi
RECORTAR/DESMAPAR Zvol sobre iSCSI

Actualmente estoy configurando una SAN para arranque sin disco. Mi backend consta de ZFS-Vol compartido a través de iSCSI. Hasta ahora todo funciona bien excepto TRIM/UNMAP. Para fines de prueba, configuré dos máquinas virtuales que ejecutan Ubuntu20.04 en VirtualBox conectadas en red a través de una red interna con direcciones IPv4 estáticas. En el objetivo (tgt) obtuve una segunda unidad virtual formateada con ZFS. En este zpool creé un zVol y lo formateé con GPT y ext4.

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

En el iniciador (open-iscsi) utilizo este comando para provocar una operación TRIM:

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

pero el shell responde con "fstrim: /iscsi-share: la opción de descarte no es compatible". Si emito esos comandos en la máquina de destino, la propiedad "REFERIR" de zVol disminuye como se esperaba.

Como no encontré nada mientras buscaba en la web, no encontré ninguna pista de por qué esto no funciona o si es posible.

Editar: Como recibí el consejo de usar la opciónaprovisionamiento_delgado.

Después de reparticionar la unidad y montarla en el iniciador, recibí un mensaje de error blk_update_request: critical target error, dev sdb, sector 23784 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0 para varios sectores y después de crear y eliminar mi archivo de prueba, fstrimenvié el mensaje.

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

Editar: Como hubo respuestas que se refieren alioAhora también probé targetcli. Allí configuro un objetivo con mi zVol en /backstores/block/iscsi y set attribute emultate_tpu=1. Después de importar esto a mi iniciador, lo particioné, lo formateé y lo monté en el iniciador. Luego creé mi archivo de prueba, lo eliminé, emití el fstrimcomando y funcionó. Gracias por la ayuda.

Respuesta1

LIO desactiva UNMAP de forma predeterminada. Si desea habilitarlo, debe establecer el emulate_tpuatributo en el objetivo.

Respuesta2

Lo que estás preguntando es muy específico de la implementación de objetivos iSCSI. La mayoría de ellos no realizan mapeo de comandos SCSI 1:1, por lo que si el destino iSCSI emula el disco duro, no omitirá los comandos no reconocidos (incluido UNMAP, por supuesto) al almacenamiento subyacente @ back-end A MENOS que le pregunte explícitamente a iSCSI. objetivo de hacerlo. Con TGT, mencionó que especificó "thin_provisioning=1" para su LUN virtual en el archivo de configuración.

Respuesta3

TRIM está habilitado de forma predeterminada para ejecutarse semanalmente en Ubuntu 20.04, por lo que no debería haber ningún problema incluso si lo ejecuta manualmente. Puedes comprobar esto en fstrim.service y fstrim.timer por si acaso:https://askubuntu.com/questions/1034169/is-trim-enabled-on-my-ubuntu-18-04-installation

Sin embargo, parece que es necesario habilitar UNMAP en el objetivo, como ya se mencionó. Dado que muchos SSD SATA tenían problemas con UNMAP, estaba deshabilitado en LIO de forma predeterminada:http://www.linux-iscsi.org/Doc/LIO%20Admin%20Manual.pdf.

Por cierto, las cosas se vuelven mucho más fáciles cuando un objetivo iSCSI admite de forma nativa TRIM/UNMAP sin más ajustes. Aquí hay un ejemplo:https://forums.starwindsoftware.com/viewtopic.php?f=5&t=5343

información relacionada