Re: Patch [0/3] Support eager_unmap for non ldpme sd devs

Martin K. Petersen
2025-07-31T04:43:02Z

Hi Kurt!

> Some docs mention LBPME in context of thin provisioning, which
> is not a good description of what SSDs/NVMes do.

Logical Block Provisioning is how discard and other capacity
provisioning primitives are defined in SCSI. SCSI devices which support
unmapping logical blocks are required to set LBPME. This includes SCSI
SSDs which support "discards" as well as storage arrays which implement
thin provisioning.

LBPME was originally called TPE since it concerned itself with thin
provisioning only. The flag was later renamed to accommodate devices
using other provisioning models.

> One could argue that the NVMe-SCSI translation is incomplete and
> should be fixed, but that discussion is now many years late.

Unfortunately SCSI-NVMe translation isn't standardized the same way as
SCSI-ATA translation is.

Implementing SCSI-NVMe translation requires an appropriate understanding
of both protocols. There is no formal translation specification to rely
on.

> Linux nvme driver don't care about LBPME.

The Linux NVMe driver doesn't know about SCSI protocol flags. The
protocol translation is being done by your enclosure's bridge device.

The flag corresponding to LBPME in NVMe is the DSM flag in ONCS in
IDENTIFY CONTROLLER. That is what your bridge firmware should have
translated to LBPME=1.

The flag corresponding to LBPME in ATA is TRIM SUPPORTED in IDENTIFY
DEVICE. It appears your device handled that translation correctly.

> Remaining question is whether we'd recommend users to use a set of
> udev rules to fix up or whether we have a sd_mod parameter to ignore
> LBPME (if LBPU/LBPWS/LBPWS10 are set) or even ignore it by default
> (and only provide an opt-out parameter).

The SCSI spec requires devices to set LBPME=1 to enable Logical Block
Provisioning. This is not optional. It is perfectly reasonable for a
device to report LBPWS to indicate that the WRITE SAME(16) command is
implemented. That does not imply that Logical Block Provisioning is
actually enabled. You could plug a hard disk into your enclosure, for
instance, and therefore LBPME would be 0 despite the bridge indicating
support for WRITE SAME(16).

We are not going to add an option to ignore LBPME. It is one of the most
reliable "does this device know what it is doing?" heuristics we have.
And we really can not trust a device which fails to handle even the
most basic bits of the SCSI protocol.

Twiddling the sysfs file via a udev rule is the appropriate way for
users to enable discards on devices which fail to implement the spec
correctly.

--
Martin K. Petersen