Bug#1038636: blkdiscard: it is too naive about larges discard unit

[Michael Tokarev]

Package: util-linux
Version: 2.38.1-5+b1
Severity: normal
Tags: upstream

Many devices has maximum discard size, DISC-MAX in `lsblk --discard` output.
However, blkdiscard by default is doing full-device discard, which is also
specified in its manual page. This results in errors and some drivers turning
discard support off. For example:

# cat /sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/usb2/2-4/2-4:1.0/host6/target6:0:0/6:0:0:0/scsi_disk/6:0:0:0/provisioning_mode
unmap
# lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 4G 0

# blkdiscard -f -l 4G /dev/sda
blkdiscard: Operation forced, data will be lost!
#### this works

# blkdiscard -f -l 5G /dev/sda
blkdiscard: /dev/sda: BLKDISCARD ioctl failed: Remote I/O error

# cat /sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/usb2/2-4/2-4:1.0/host6/target6:0:0/6:0:0:0/scsi_disk/6:0:0:0/provisioning_mode
disabled

Kernel log:

[217264.437619] sd 6:0:0:0: [sda] tag#8 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[217264.437632] sd 6:0:0:0: [sda] tag#8 Sense Key : Illegal Request [current]
[217264.437638] sd 6:0:0:0: [sda] tag#8 Add. Sense: Invalid field in cdb
[217264.437645] sd 6:0:0:0: [sda] tag#8 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[217264.437648] critical target error, dev sda, sector 134217728 op 0x3:(DISCARD) flags 0x4000 phys_seg 1 prio class 2

Having said this, I'm not really sure who's in charge here.
Maybe it is the kernel driver who should split the large request into smaller parts.

But the end result is that whole thing stops working (and some devices even fall
off the usb bus and needs to be re-set). And for quite some times I was sure
discard/trim is not supported on USB-connected devices at all, just because this
quick blkdiscard test always fails like this, - and I thought it is the command
which is illegal, not its parameter.

[Chris Hofstaedtler]

Hi Michael,

* Michael Tokarev <m...@tls.msk.ru> [230619 13:00]:

> Having said this, I'm not really sure who's in charge here.
> Maybe it is the kernel driver who should split the large request into smaller parts.
>
> But the end result is that whole thing stops working (and some devices even fall
> off the usb bus and needs to be re-set). And for quite some times I was sure
> discard/trim is not supported on USB-connected devices at all, just because this
> quick blkdiscard test always fails like this, - and I thought it is the command
> which is illegal, not its parameter.

I'm not sure what you're asking. Is this a bug? A feature request?

blkdiscard is a "low level tool" and I think it works according to
its documentation. A less low-level tool is fstrim, that might do
what you want?

If you want blkdiscard to be smarter - if the smartness shouldn't be
in the kernel in the first place - can you suggest this to upstream?
Doesn't seem like this is a Debian-specific thing?

Thanks,
Chris

[Michael Tokarev]

19.06.2023 14:14, Chris Hofstaedtler wrote:

> I'm not sure what you're asking. Is this a bug? A feature request?
>
> blkdiscard is a "low level tool" and I think it works according to
> its documentation. A less low-level tool is fstrim, that might do
> what you want?
>
> If you want blkdiscard to be smarter - if the smartness shouldn't be
> in the kernel in the first place - can you suggest this to upstream?
> Doesn't seem like this is a Debian-specific thing?

It definitely is not debian-specific, this is why I tagged it "upstream"
to begin with.

Note that `lsblk' utility also belongs to the same util-linux package,
and this utility knows how to find the max unmap size, so it's just a
missing call to already existing functionality.

Yes, blkdiscard works according to the docs, but since it is used in
particular scenarios, I'd say it is a bug on its part.

Why I'm filing it with debian: because it needs to be documented at
the very least. Usually when someone bug one of the software I
maintain in debian, I can know better how to contact upstream on
behalf of this reporter, or when a problem is complex or too
specific to particular user's setup so I can't reproduce it, I
suggest them to ask upstream directly. It is about knowing packages
you maintain. In recent years I had to register in just too many
places and subscribe to too many mailing lists just to be able to
report issues/bugs. I tend to avoid doing so unless really
necessary. If you don't have util-linux upstream contacts, I
can register/subscribe there for sure...

Thanks,

/mjt