On 9 Jan 2024 at 0:20, d tbsky wrote: > > Since I am using RedHat family, I focus at q35 machine type > (pc-i440fx is no longer supported) and virtio-blk/virtio-scsi > device. > ... > > trim is useful for ssd and sparse image file and I am using it. but > for hard disk I don't want extra layers to slow it down. so I use > thick-provisiond lvm device for vm disk backend. >
Oh I see. You're saying that -drive ...,discard=ignore Does not prevent Windows (guest OS) from trying the discard=trim=unmap on the virtio disk device, merely those operations get ignored by QEMU. Thus, Windows thinks it's trimming, while in reality it's just wasting time on void request+response transactions... You're saying that apparently, virtio-blk or virtio-scsi still advertise the availability of that command (via SCSI INQUIRY / Vital Product Data / LBPU bit), or Windows understand that this is a virtio drive and just assumes that discard is available... Hmm. I've just tried googling, if there's a way to do SCSI Command pass-through from the guest OS to the host-side physical SCSI device (should also work for SATA, if I understand correctly). Here is what I've found: https://gist.github.com/amshinde/b9b2763cb3f6752508ca522f41b583ca i.e. it's three cmdline args to qemu-system: 1x -drive + 2x -device. Personally I've never done this. I always just specify the device node for a "file" in "raw" mode. Also, I'd expect that the SCSI command passthrough could actually be slower for routine operation, because it doesn't make use of the block-level cache integrated with the host's (HV's) memory management... I still think the SCSI or IDE style emulated controller might just do the trick, but I have no clue if your RedHat build of QEMU still offers those options. In Debian, I tend to compile my own from upstream source code, because the distro package tends to be old and lack recent features. Fortunately my machines using qemu are on the experimental side :-) and can take a bit of punk / no harm done if something doesn't work. Frank
