Thank you! I'll be waiting for any updates then.
Thank you! I'll be waiting for any updates then.
@mad-jester It looks like that particular upgrade path requires an ARM system so we will have to test it on an RPi. That does not help the vast majority of users. Further research indicates the provisioning_mode has to be changed for Linux to ignore the LBPME bit set on the bridge and it seems modifying the firmware is possible by user also. There are some threads out there on this, including with users saying Windows ignores the bit anyway.
@Sabrent I can use Windows to upgrade it if necessary. If that can be fixed to work.
I don't completely understand what is LBPME bit - is it necessary for flashing or working? I assume it's for working, because if Windows ignores it, then it can't be the reason why I can't flash it on Windows. In this case, it's probably fixed in the new firmware, isn't it?..
@mad-jester The bit is apparently set at the factory for the device. It basically says to enable TRIM/UNMAP automatically. This does not mean the device cannot support the function, just that TRIM must be manually enabled. Users have forced this on Linux to work correctly. DeleteNotify in Windows should work regardless and some users report it working, aside from firmware hacks. Since there is no guarantee we are moving to a newer chipset. The firmware hack as suggested is for ARM hardware (ODROID) which is not exactly ideal. We are not aware of a way to force this on Windows but theoretically is possible through modification of firmware, but we are having difficulty getting this done in an official capacity possibly due to product segmentation.
I've investigated this more thoroughly.
Indeed, there are people with JMS567/JMS578 who see TRIM not being enabled by default. They have listed the instructions to manually enable TRIM, after which it works. In my case, however, it does not work even after manually enabling it. There is one place where you can actually see this: after enabling TRIM, it should give you the maximum unmap size, and in my case, it says "Unmap not implemented".
https://wiki.gentoo.org/wiki/Discard_over_USB - under "Investigate support", it says "...means that trim is not supported, so stop there". That's what I'm getting by following this guide.
Regarding Windows, I have a suspicion that maybe it actually does not work, but doesn't throw any error and pretends to work?.. That's the only explanation I could come up with. You wrote earlier that you see "UASP enabled" in some programs, but the performance is not BOT. Maybe this is because UASP is actually NOT enabled, hence the speed, and either those programs are wrong, or Windows reports "It's enabled! ...But doesn't work, but who cares about that". And that could why updaters don't work - it's trying to send SCSI commands, but UASP does not work, so those commands fail.
In other places, I see mentions that it does not work on old firmwares, so I guess the only thing to do is update the firmware somehow. Any idea why it does not work? What do you use to update it?
@mad-jester This all looks correct. UASP is working, although we have had some configurations revert to USB (BOT) in some cases. The UNMAP workaround does not work for all bridges, that is setting the provisioning mode to UNMAP. There is a bit on the bridge that lets it state support to the host and that's 0 on the JMS567 but it seems Windows ignores this anyway and will report successful TRIM in some cases. This is not something the factory will change. All future products of ours will explicitly have everything enabled from the factory, as we have now requested, since we have had difficulty reproducing the conditions consistently, which means no more JMS567.
It does seem that JMS578 firmware can be modified for it but so far we have only had people do it on ARM with the JMS567, problematic since our office has 0 such devices. We aim to change that particularly as we want to test the Surface Pro 9 in both varieties with the Rocket 2230. In fact, we've found the SP9 only runs SSDs at PCIe 3.0 even on Intel, but that's a different topic. I would have to test this on my own time as I do have some RPis. In any case, we could not get any firmware update working for this on Windows. We have an in-house programmer but we are limited by what we are given from the factory which means we'd have to modify this ourselves and distribution of said firmware would possibly be disallowed.
I appreciate the follow-up. There's a lot of material out there on this but some of it is conflicting. I'm not convinced it's impossible to make it work but you are correct that reporting is one thing, actual working state another. I have no doubt there are people capable of determining the real issue but from our perspective we want something sanctioned.
I was misunderstanding what BOT means; I thought it meant UASP, but it actually means "NOT UASP".
You said that "users have forced this on Linux to work correctly", but according to what I see, they have not. They have noticed another problem - that is, even with LBPME set to 1, UNMAP is not automatically enabled in Linux. And for that, there is that guide on how to enable it. I thought that was what you meant, and this would force the LBPME bit to be ignored, but now I see that it's a different thing.
All I can find is that it's impossible, and an attempt to make it possible was rejected for obvious reasons: https://www.spinics.net/lists/linux-scsi/msg95062.html
So, if I understand everything correctly now, this seems like an unsolvable problem for me: I can't try a different firmware, and I can't override this in Linux. So now I'm back to Plan B: can I return the device based on this?
Switching this model to another chipset is probably going to take a very long time, isn't it?.. On top of that, I'd have to wait until you blow through all your existing stock to get one that's definitely "new". As I understand, the time frame for such changes is closer to years rather than months, right?
https://wiki.archlinux.org/title/Solid_state_drive#External_SSD_with_TRIM_support
I'm reading this one more time more carefully. So, first they check sg_readcap to get the LBPME bit, which is 0. Next, they check sg_vpd, which reports the "Unmap Command Supported (LBPU)" bit. In this example, it's 1, so we know that it's actually supported, and can enable it manually. In my case, it's also 0.
So seems like my original understanding was correct:
- When LBPME is set to 1, it gets picked up by the kernel and "just works"
- When LBPME is set to 0, the kernel does not enable UNMAP
- If LBPU is 1, then UNMAP is actually supported, so we switch it on manually in provisioning_mode (a fairly common situation)
- If LBPU is 0, then UNMAP is really not supported (my situation)
So not only does Windows ignore LBPME, but it also ignores LBPU. Probably because the driver was also made by the chip manufacturer, to they simply decided to ignore any bits as long as they have identified the device and know what it should be actually capable of. Or maybe it's because Linux treats the device as JMS561, which indeed does not have UNMAP.
Here is what makes me think this:
$ 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
0xdfUnit serial number VPD page:
Unit serial number: DB98765432146Device 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: DISK03Block 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]
It says "not implemented" - which could mean "in the driver", or in the firmware. Either way, it's not the common and fixable situation of one bit not set correctly. It's a problem on a whole another level.
Oh, those chip manufacturers. Who needs SCSI specifications when it "works on Windows (R)"? x_x
BTW you can try the ARM flasher on amd64 using qemu-system-arm and qemu-user . It allows running foreign architecture code without even a virtual machine. But for me, it did not work for some reason. I'm curious if it will be any difference on a real Raspberry Pi. I assumed that it did not work because it expects some particular hardware, but now I'm pretty sure it won't work on a Pi either, for the same reason it does not work on Windows (a firmware that's too broken to be reflashed).
@Sabrent
The Linux kernel team has confirmed that there's nothing that can be done to make this device work properly.
Can I return this device based on this situation?
(Also, can I subscribe to receive email notifications about new posts in topics where I've posted or where I'm mentioned or replied to? The "Email notifications" checkbox in my profile is checked, but I'm not receiving any notifications - which is why I'm so slow at noticing a reply.)
@mad-jester Thank you for the update. I appeciate the research and time you spent. Yes, you should return the device if it does not meet the specifications. If you have difficulty let me know. We will look into the email notifications as well.
Then I have to choose something else instead of this one.
The "fixed" revision of this model is not going to happen any time soon, most likely not this year, correct?
A possible solution is a HB-U930 USB hub with six EC-UASP enclosures. The hub should have enough power for this many drives. That's a lot of devices, and I won't be able to return all of them if the whole solution does not work properly, so I have to be especially careful.
Are there any caveats I should know about HB-U930 ? I see it has two chained USB controllers; that probably shouldn't be an issue, but I don't know the USB protocols very well to know the implications.
And about EC-UASP:
- You wrote earlier that those will be either JMS578 or ASM1053E . Do you know which ones are in stock at the moment? Would it be possible to specifically get an ASM1053E one somehow?
- Are they actually JMS578 / ASM1053E , and not JMS567 / ASM1051E with "updated" firmwares? I'm sorry for asking, but I wouldn't ask if we didn't just have a problem with a JMS567 pretending to be JMS561U , possibly fixed by pretending to be JMS578... Amd ASM1051E has issues with sector translation, which might be working under Windows, but causes data corruption on Linux.
- Has their firmware beed modified? Do they actually identify correctly on Linux, support UASP and TRIM on Linux at the same time without manually overriding the bits?
- You wrote that any possible issues would be fixed with a firmware update. Has anyone actually tried updating the firmware on both of those, does it work? Is there a firmware updater available for Linux amd64 , and if so, does it work? Are there currently applicable firmware updates that I should apply right away to avoid potential issues? (I don't mind having to "fix" a device right away before using it, as long as there is an available, working flashing procedure.)
- Does it automatically put drives into sleep mode after 10 minutes of inactivity (on the suggested firmware)? Does it override the drive name the same way DS-4SSD does? (For some reason, drives identify as something like SABRENT03 instead of their actual identification string. Moreover, the device itself identifies as "Go To Final Lap"...)
@Sabrent I forgot to mention you again - sorry, I can't get used to this workflow. :)
@mad-jester I have no updated information on the EC-UASP at this time. The original one we have here to test works fine with TRIM, so again this is an odd issue. We are simply moving to guarantee it with the JMS578. In reference to the DS-4SSD, we were informed it is a matter of TRIM not being enabled for multiple drives with a basic chipset, which is a different issue.
While we have a user manipulate the hardware with an ODROID it is not something we can support. Inactivity may be controlled by firmware, host, or both, and users have modified firmware for other units to adjust such things but we do not officially support that. Being careful with the name may apply in some cases of OEM Acronis compatibility.
The HB-U930 has plenty of power, yes, up to 48W total by power supply. The HB-BUP7 may also work, which uses the RTS411S, but the 10-port version offers more power.
@Sabrent There seems to be some miscommunication here...
> I have no updated information on the EC-UASP at this time. The original one we have here to test works fine with TRIM, so again this is an odd issue. We are simply moving to guarantee it with the JMS578.
You talking about EC-UASP, right?.. But it's already on JMS578, isn't it?.. Or are they actually on a JMS567 pretending to be JMS578, so you are "moving" them as well?
I was asking about EC-UASP that I'm going to replace my device with. Were they tested on Linux? How are the bits and firmware upgrading there? Does it require an upgrade immediately to fix known issues? Are there any known issues such as disks spinning down, disk model overriding, wrong identification, wrong bits?
@mad-jester Current ones should be JMS578, yes. Its characteristics are well-known and well-supported. I have seen custom user firmware but there should be no issues.
