On 13/03/23 11:55, darkpenguin wrote: > Hello, > > Short version: is it possible to force ignore the LBPME bit and use > UNMAP anyway? Maybe via quirks? > > Long version: I've got a JMS567-based DAS from Sabrent (DS-4SSD) that > has an, um, "weird" firmware (they've tweaked it for their reasons, and > now it even refuses to reflash). It identifies as 152d:1561 (JMS561), > and does not have the LBPME bit set. However, they say that Windows > ignores this bit, and works just fine, which is why they never noticed > the problem. So it's definitely actually supported. > > I've seen a proposed patch that enables the same behaviour, but it was > rejected for obvious reasons: > https://www.spinics.net/lists/linux-scsi/msg95062.html > But in the bottom, it was suggested that this might be better > implemented via quirking. > > Is there currently a way to force UNMAP on this device regardless of the > LBPME bit? Was it implemented by quirking? I would prefer to avoid using > a patched kernel, and I'm not even sure if that patch would still be > (correctly) applicable to a modern kernel. > > (Please CC me, I'm not on the list.) Followup: judging by this https://wiki.archlinux.org/title/Solid_state_drive#External_SSD_with_TRIM_support , my problem actually goes even deeper. I see that you can override the wrongly-set LBPME bit by switching provisioning_mode manually. In my case though, the LBPU bit is also 0. Argh... My assumption is that the Windows driver is also made by the chip manufacturer, so it ignores all the bits as long as it knows what the identified device should be capable of. I can switch provisioning_mode, but after that, if I issue a blkdiscard command of any size, I get an error, and provisioning_mode goes to "disabled". Maybe it's because the kernel treats this device as JMS561 (as advertised by the device), which does not support UNMAP? This is what gives me this idea: $ sudo sg_vpd -a /dev/sdc Supported VPD pages VPD page: Supported VPD pages [sv] Unit serial number [sn] Device identification [di] Block limits (SBC) [bl] Logical block provisioning (SBC) [lbpv] 0xde 0xdf Unit serial number VPD page: Unit serial number: DB98765432146 Device Identification VPD page: Addressed logical unit: designator type: NAA, code set: Binary 0x3042987654321460 designator type: T10 vendor identification, code set: ASCII vendor id: SABRENT vendor specific: DISK03 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: 65535 blocks Maximum unmap LBA count: 0 [Unmap command not implemented] Maximum unmap block descriptor count: 0 [Unmap command not implemented] Optimal unmap granularity: 0 blocks [not reported] 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] Logical block provisioning VPD page (SBC): Unmap command supported (LBPU): 0 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: 1 Descriptor present (DP): 0 Minimum percentage: 0 [not reported] Provisioning type: 0 (not known or fully provisioned) Threshold percentage: 0 [percentages not supported] Only hex output supported VPD page code=0xde: 00 00 de 00 0c 4a 4d 00 00 00 00 00 00 00 00 00 00 ....JM.......... Only hex output supported VPD page code=0xdf: 00 00 df 00 11 4a 4d 00 00 00 00 00 00 00 00 00 00 ....JM.......... 10 00 00 00 00 00 So... anything I can try in this situation?..
