Actually, did blkdiscard reset your device (according to udevadm monitor) and provisioning_mode, like in my case? I’m guessing it didn’t, since you did something similar with fstrim before and blkdiscard nevertheless succeeded.
Come to think of it, TRIM might still work even if the unmodified data is returned. 
Since you remember it previously at least giving the impression that it worked, you could now retry the blkdiscard stuff with an old enough template and VM kernel version for sys-usb.
Possible but perhaps pointless, considering the recent results. Thanks for the idea though 
Maybe not, but it’s hard debug automation when it doesn’t even work manually.
Well, I guess it depends on how we look at it.
What actually works manually is setting the unmap in provisioning_mode. AFAICS, that is unrelated to whether actual discarding works or not. So, the udev rules related to that part only.
Or am I missing something?
Actually, did blkdiscard reset your device (according to
udevadm monitor) andprovisioning_mode, like in my case?
No idea. How do I check?
Come to think of it, TRIM might still work even if the unmodified data is returned.
Well, TRIM does not actually write anything in the data blocks, right? So, perhaps the expectation of all zeros doesn’t match that? AFAIK, trimming happens inside the internal address map of the device (firmware), not on the FS.
Thinking further myself, writing zeros would contradict the essential idea of TRIM: reduction of write amplification.
“However, after the TRIM command is issued and garbage collection has taken place, data recovery can become difficult or impossible, depending on the drive’s firmware implementation of the command.”
Do we know anything about garbage collection taking place?
The Samsung and Western Digital SSDs I’ve used so far all seemed to have RZAT (Deterministic Read Zero After TRIM). I assumed that even drives without this property would return at least slightly changed data, but who knows.
Look into the provisioning_mode file after, and at udevadm monitor output (saying IIRC that the device was removed and added again) during blkdiscard.
Look into the
provisioning_modefile after, and atudevadm monitoroutput (saying IIRC that the device was removed and added again) duringblkdiscard.
root@sys-usb:~ # echo unmap >/sys/block/sda/device/scsi_disk/*/provisioning_mode
root@sys-usb:~ # cat /dev/random >/dev/sda2
cat: write error: No space left on device
root@sys-usb:~ # sha256sum /dev/sda2 >checksum.txt
root@sys-usb:~ # blkdiscard -f /dev/sda2
blkdiscard: Operation forced, data will be lost!
root@sys-usb:~ # cat /sys/block/sda/device/scsi_disk/*/provisioning_mode
unmap
and the other terminal shows this upon blkdiscard:
root@sys-usb:~ # udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[13094.979673] change /devices/pci0000:00/0000:00:06.0/usb3/3-2/3-2:1.0/host2/target2:0:0/2:0:0:0/block/sda/sda2 (block)
UDEV [13095.091229] change /devices/pci0000:00/0000:00:06.0/usb3/3-2/3-2:1.0/host2/target2:0:0/2:0:0:0/block/sda/sda2 (block)
What do we learn from this?
That udevadm monitor output is actually what I see too on blkdiscard. I probably misremembered remove/add events.
Here on my system it seems that the original udev rule sets unmap too early, so that it is clobbered back to full. Changing the rule like this fixed it for me:
ACTION=="add|change", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", ATTR{../../scsi_disk/*/provisioning_mode}="unmap"Thanks! That rule works for me too.
Here on my system it seems that the original udev rule sets
unmaptoo early, so that it is clobbered back tofull.
That seems to be the issue here too. Why does this happen and how exactly the new rule overcomes it?
What causes the clobbering in the first place, I don’t know.
Someone apparently experienced it outside of a Qubes OS context in https://askubuntu.com/a/1499305 and the cursed workaround partially worked for me, after bumping up sleep to 10 seconds.
Then I looked at udevadm monitor output and picked some event that happens as late as possible (the block subsystem add/change event) and rewrote the udev rule for that. Luckily,
ATTR{...}= supports * globs.
Thanks for the additional info!
So, obviously it is not a Qubes issue.
I still wonder if it is a bug or where to search if it has been reported.
What do you think?
¯\_ (ツ)_/¯
Using the exact same DVM template and udev rules, just in 4.3.0 and switched from debian-12-xfce to debian-13-xfce. Again - it stopped working unless the whole USB device (not just partition sda1 or whole volume sda) is attached to the qube.
How is it for you?
Sounds like you have the udev rule active in the wrong qube? When forwarding as a block device, the rule has to be active in the backend qube (e.g. sys-usb), not in the frontend qube.
I’m not regularly using any custom udev rules.
Sounds like you have the udev rule active in the wrong qube? When forwarding as a block device, the rule has to be active in the backend qube (e.g. sys-usb), not in the frontend qube.
You mentioned that before but having it in sys-usb seems to have no effect whatsoever, so I need to have it in the destination qube.
The different thing is that before I could TRIM even when attaching a single partition (sda1). Not any more.
Looking at udevadm monitor when attaching that partition:
KERNEL[124.583573] add /devices/vbd-51840 (xen)
KERNEL[124.586787] bind /devices/vbd-51840 (xen)
UDEV [124.586816] add /devices/vbd-51840 (xen)
UDEV [124.587213] bind /devices/vbd-51840 (xen)
KERNEL[124.602529] add /devices/virtual/bdi/202:128 (bdi)
UDEV [124.603177] add /devices/virtual/bdi/202:128 (bdi)
KERNEL[124.605264] add /devices/vbd-51840/block/xvdi (block)
UDEV [124.692201] add /devices/vbd-51840/block/xvdi (block)
Then I checked udevadm info -a /dev/xvdi and I don’t see the attributes specified in the rules:
https://paste.opensuse.org/pastes/a1a39822aae5
Do you have any idea how to make it work as before?
That’s normal, the udev rule operates on the SCSI disk level (/dev/sdX, not /dev/xvdY).
Can’t think of anything that would have changed, sorry.
Believe or not, I finally found the problem - a documentation bug!
According to man udev.conf rules can be put in /usr/local/lib/udev/udev.conf.d/*.conf. That doesn’t work though.
For your rule to work correctly, it must be in /usr/local/lib/udev/rules.d/*.conf and as you said, this can and should be put directly in sys-usb’s disposable template. After that, attaching even a single partition in a qube makes fstrim work just fine.
Phew…
Happy to hear it’s working again!
The udev.conf(.d/) location is valid too, but it’s for other kinds of udev configuration and not for rules. Probably would be a good idea if the udev.conf(5) and udev(7) manpages cross-referenced each other to point readers in the right direction.