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

Kurt Garloff
2025-07-29T07:50:36Z

Hi Martin,

On 29.07.25 07:09, Martin K. Petersen wrote:
>> The SCSI disk driver (sd_mod) would just claim that discard is not
>> supported. It's not true. The NVMes support it as do the enclosures.
> For some definition of support at least. If they can't figure out how to
> set a single bit flag to enable the feature, then maybe their "support"
> is not entirely trustworthy. But great that it works...
>
> What are your devices actually reporting in:
>
> # sg_readcap -l /dev/sdN
Read Capacity results:
Protection: prot_en=0, p_type=0, p_i_exponent=0
Logical block provisioning: lbpme=0, lbprz=0
Last LBA=3907029167 (0xe8e088af), Number of logical blocks=3907029168
Logical block length=512 bytes
Logical blocks per physical block exponent=0
Lowest aligned LBA=0
Hence:
Device size: 2000398934016 bytes, 1907729.1 MiB, 2000.40 GB, 2.00 TB

Yes, lbpme is 0.

> # sg_vpd -p bl /dev/sdN
Block limits VPD page (SBC):
Write same non-zero (WSNZ): 0
Maximum compare and write length: 0 blocks [Command not implemented]
Optimal transfer length granularity: 1 blocks
Maximum transfer length: 65535 blocks
Optimal transfer length: 65535 blocks
Maximum prefetch transfer length: 0 blocks [ignored]
Maximum unmap LBA count: 20971520
Maximum unmap block descriptor count: 1
Optimal unmap granularity: 1 blocks
Unmap granularity alignment valid: false
Unmap granularity alignment: 0 [invalid]
Maximum write same length: 0 blocks [not reported]
Maximum atomic transfer length: 0 blocks [not reported]
Atomic alignment: 0 [unaligned atomic writes permitted]
Atomic transfer length granularity: 0 [no granularity requirement
Maximum atomic transfer length with atomic boundary: 0 blocks [not
reported]
Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]

Max 10GiB unmap at a time.

> # sg_vpd -p lbpv /dev/sdN

Logical block provisioning VPD page (SBC):
Unmap command supported (LBPU): 1
Write same (16) with unmap bit supported (LBPWS): 0
Write same (10) with unmap bit supported (LBPWS10): 0
Logical block provisioning read zeros (LBPRZ): 0
Anchored LBAs supported (ANC_SUP): 0
Threshold exponent: 0 [threshold sets not supported]
Descriptor present (DP): 0
Minimum percentage: 0 [not reported]
Provisioning type: 0 (not known or fully provisioned)
Threshold percentage: 0 [percentages not supported]

LBPU is 1.

>> I have a few, though all have variants of RTL9210 chips.
>>
>> But sd was too conservative to let me do it.
> Why not just have a udev rule which does:
>
> echo unmap > /sys/class/scsi_disk/H:C:T:L/provisioning_mode
>
> ?
>
> Substitute "writesame_10" or "writesame_16" depending on what is
> actually implemented.

It does the job.

Question, as you say, is whether supporting unmap (LBPU=1) is
something to be trusted when the device says that Logical Block
Provisioning Management Enable is off.

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

Using sg_readcap on a PCIe attached NVMe indeed does not result
in LBPME being set either.

root@framekurt(//):~ [0]# sg_readcap -l /dev/nvme0n1
Read Capacity results:
Protection: prot_en=0, p_type=0, p_i_exponent=0
Logical block provisioning: lbpme=0, lbprz=0
Last LBA=8001573551 (0x1dcee52af), Number of logical blocks=8001573552
Logical block length=512 bytes
Logical blocks per physical block exponent=0
Lowest aligned LBA=0
Hence:
Device size: 4096805658624 bytes, 3907018.3 MiB, 4096.81 GB, 4.10 TB

Actually, here's the fun parts:
- The enclosures do not seem to set the LBPME bit when doing the
translation to SCSI's READ_CAPACITY_16 command, as far as I
can see. The Linux nvme driver does not do it either nor does the
NVMe SCSI translation guide[*] even mention it.
- The nvme driver just relies on the dataset management bit (which the
SCSI translation guide 1:1 relates to LBPU from VPD 0x82 lbpv).
- Attaching the same PCIe device in a USB enclosure of course results in
the SD driver being used who does not see LBPME being set.
- An old SATA NVMe in the same enclosure actually does report LBPME=1
and the (unpatched) SD driver happily uses the advertised unmap.

[*]
https://www.nvmexpress.org/wp-content/uploads/NVM-Express-SCSI-Translation-Reference-1_1-Gold.pdf

My conclusion:
- Neither the Linux nvme driver nor USB enclosure firmware nor the
NVMe-SCSI translation guide seem to emulate the LBPME bit for
devices with unmap/ws/ws10 support.
- SATA NVMEs do seem to set LBPME=1 and the SD driver requires it.

One could argue that the NVMe-SCSI translation is incomplete and
should be fixed, but that discussion is now many years late.
I guess that other OS drivers do not require LBPME=1, which is
why the translation guide and subsequently firmwares and even the
Linux nvme driver don't care about LBPME. The SD driver probably
should be told to not care either ...

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).

Best,