## Host environment - Operating system: Debian GNU/Linux 13 (trixie) - OS/kernel version: Linux 6.12.90+deb13.1-amd64 x86_64 (Debian kernel) - Architecture: x86_64 - QEMU flavor: qemu-io / qemu-img / qemu-system-x86_64 (block/iscsi.c driver, libiscsi 1.20.0) - QEMU version: qemu.git master, `qemu-img version 11.1.50 (v11.1.0-1468-g5f664cd37a)`, built from source. Also reproduced with Debian's 1:10.0.13+ds-0+deb13u1 and Proxmox VE's pve-qemu-kvm 11.0.3-3. - QEMU command line: ``` # 20 block-status queries of 1 MiB each against an iSCSI LUN ./qemu-io -r -f raw iscsi://127.0.0.1/iqn.2026-09.org.example:lbatest/0 \ -c "alloc 0 1M" -c "alloc 1M 1M" -c "alloc 2M 1M" ... -c "alloc 19M 1M" ``` ## Emulated/Virtualized environment - Operating system: not applicable; reproduces with qemu-io and no guest. First observed with qemu-system-x86_64 (Proxmox VE 9, Debian 13 guests) during backup jobs. - OS/kernel version: n/a - Architecture: n/a ## Description of problem `iscsi_co_block_status()` in `block/iscsi.c` sends GET LBA STATUS whenever the LUN advertised LBPME in READ CAPACITY(16). Some common targets set LBPME (they support UNMAP) but do not implement GET LBA STATUS at all. The Linux kernel target (LIO) is the prominent example: `sbc_parse_cdb()` in `drivers/target/target_core_sbc.c` handles only READ CAPACITY(16) and REPORT REFERRALS under SERVICE ACTION IN(16); anything else hits the default branch, which logs `Unsupported SA: 0x12` at KERN_ERR and fails the command with ILLEGAL REQUEST / INVALID FIELD IN CDB. SCST behaves the same way. QEMU handles the failure gracefully, printing ``` qemu-io: iSCSI GET_LBA_STATUS failed at lba 2048: SENSE KEY:ILLEGAL_REQUEST(5) ASCQ:INVALID_FIELD_IN_CDB(0x2400) ``` and treating the range as allocated. But it then sends the very same command for the next range, so every block-status-driven operation (backup via block-copy, drive-mirror, `qemu-img convert` / `map`) produces one error line per cluster on the initiator and one kernel log line per cluster on the target, for the whole life of the BlockDriverState. The scale in practice: a Proxmox VE node backing up 42 LUNs from a Linux 6.12 LIO target (ZFS zvols, iblock backstores, `emulate_tpu=1`) produces 2,037,893 `Unsupported SA: 0x12` kernel messages on the target and the same number of `error_report()` lines on the hypervisor in one night. The target-side messages are unconditional `pr_err()`, so they also churn the kernel ring buffer and syslog on the storage server. The result of the operation is correct; this is purely a "keeps asking a question it has already been told the answer to" problem. Expected behaviour: after the target answers GET LBA STATUS with ILLEGAL REQUEST and INVALID FIELD IN CDB (or INVALID OPERATION CODE), the driver should stop sending it for that LUN and take the existing "all allocated" fast path, exactly as it already does for WRITE SAME. Commit 27898a5daa ("iscsi: recognize "invalid field" ASCQ from WRITE SAME command") treats INVALID FIELD IN CDB like INVALID OPERATION CODE, and commit dbe5c58f2a ("block/iscsi: allow fall back to WRITE SAME without UNMAP") clears the corresponding capability bit so the rejected variant is not sent again. GET LBA STATUS needs the same treatment: one warning, then clear `lbpme` for the LUN. `lbpme` is re-read from READ CAPACITY(16) on reopen, so a target that gains support would be picked up again. ## Steps to reproduce 1. On a Linux host with `targetcli-fb`, create a loopback LIO target whose LUN advertises LBPME but, like every LIO version, lacks GET LBA STATUS: ``` targetcli /backstores/fileio create name=lbatest file_or_dev=/tmp/lbatest.img size=1G sparse=true targetcli /backstores/fileio/lbatest set attribute emulate_tpu=1 targetcli /iscsi create iqn.2026-09.org.example:lbatest targetcli /iscsi/iqn.2026-09.org.example:lbatest/tpg1/luns create /backstores/fileio/lbatest targetcli /iscsi/iqn.2026-09.org.example:lbatest/tpg1/portals delete 0.0.0.0 3260 targetcli /iscsi/iqn.2026-09.org.example:lbatest/tpg1/portals create 127.0.0.1 3260 targetcli /iscsi/iqn.2026-09.org.example:lbatest/tpg1 set attribute generate_node_acls=1 demo_mode_write_protect=0 authentication=0 ``` 2. Run the qemu-io command above (20 `alloc` commands, one per 1 MiB) with a QEMU built with `--enable-libiscsi`. 3. Observe 20 `iSCSI GET_LBA_STATUS failed at lba N: SENSE KEY:ILLEGAL_REQUEST(5) ASCQ:INVALID_FIELD_IN_CDB(0x2400)` lines on stderr and 20 new `Unsupported SA: 0x12` lines in `dmesg`, one per query. Every `alloc` still correctly reports the range as allocated. 4. Control: `targetcli /backstores/fileio/lbatest set attribute emulate_tpu=0` (clears LBPME) and repeat: no GET LBA STATUS is sent and nothing is logged. Results on master v11.1.0-1468-g5f664cd37a: | binary | target kernel messages | initiator stderr lines | alloc answers | |---|---|---|---| | Debian qemu-io 10.0.13 | 20 | 20 | 20 allocated | | master 11.1.50 | 20 | 20 | 20 allocated | | master 11.1.50 with the LUN's `emulate_tpu=0` | 0 | 0 | 20 allocated | ## Additional information - Linux target code path: https://github.com/torvalds/linux/blob/master/drivers/target/target_core_sbc.c (`case SERVICE_ACTION_IN_16` in `sbc_parse_cdb()`; only `SAI_READ_CAPACITY_16` and `SAI_REPORT_REFERRALS` are handled). LBPME is set in `sbc_emulate_readcapacity_16()` when `emulate_tpu` or `emulate_tpws` is enabled. - Proxmox VE's ZFS-over-iSCSI plugin sets `emulate_tpu=1` on every LUN it creates, so every user of that plugin with a LIO target hits this on every backup. Proxmox bug, open since 2022, with the same analysis by a Proxmox developer: https://bugzilla.proxmox.com/show_bug.cgi?id=4046 - Same symptom with SCST as the target (2016): https://sourceforge.net/p/scst/mailman/message/35241011/ - Same symptom with TrueNAS SCALE targets: https://github.com/TheGrandWazoo/freenas-proxmox/issues/203 - I have a small patch implementing the fallback described above, tested against the loopback target and in production (the 2,037,893 messages per night became 29, one per LUN opened, with identical backup results). - This report (and the patch) were co-authored by Claude Fable 5.1 using high effort.