Hello world,

I have inherited a legacy of serving a 7 years old wd data60 jbod enclosure. I have tried replacing one of failed WUS721010AL5204 drives with DKR2H-H10RSS - native SKU is quite hard to buy at the moment. Funny thing is that the enclosure finds this new HDD unsupported - kindly see extract from jbod's drives listing below the post.

My question is - is it worth flashing this drive using hugo and an appropriate sas hba with some firmware for WUS7210 found at file archive on this site? Maybe someone has hit the same problem?



Many thanks in advance!

BR, Cyrill

Some old enclosures suffer from LBA22 and LBA24 limitations. I suggest a more recent box such as the Blueendless BS-MR35T I use now. The Blueendless has USB ports on it for daisy chaining as desired to the the USB limits.

_________________
USB 3.5" enclosures are $19 USD postage paid from China, I own several

DKR2H-H10RSS - drive from Hitachi's VSP. SCSI "write" command is locked. You are need to unlock or reflash this drive. Best way is to return it to seller.

@Hardcore games - the enclosure in discussion is a bit bigger than Blueendless USB - basically it can inherit up to 60 HDDs


@E123, I can return it, but I don't have any replacement - so question is more like "what firmware should I use".
In fact, WD Data60 and Hitachi SE4U60 are pretty much the same hardware, but seems to be different in firmware.

Possibly, but not necessarily true. I have just acquired access to two VSP systems with a total of ten of the 60-bay SAS shelves (aka DW-F1000-DB60) at work. They have retired a couple of systems that were part of a mirrored pair across the university's campus. This is the second time I have had access to drives from retired VSPs.

They are stuffed full of DKR2H-H10RSS/HUH721010AL5204 drives with a smattering of DKS2N-H10RSS/DKS2O-H10RSS, aka ST10000NM002G/ST10000NM013G, from failed drive replacements over the years. These are all 10TB SAS drives.

Now, on the drives from the previous VSPs, I got access to you, and you are correct, the firmware is locked to accept only SCSI WRITE AND VERIFY commands. There were two 4TB drive types in that system. Hundreds of ST4000NM0023 shipped with the system, and replacement ST4000NM0025 drives for failed ones. I was able to flash the ST4000NM0023 drives with E007 firmware and get them working. However, I was never able to get the ST4000NM0025 drives to work. Though, to be honest, I didn't try that hard, since when you have a few hundred drives that work, you are not going to bother with the ~30 problematic ones.

Now, all these drives are by default formatted with extended sector sizes. In the case of the 4TB drives: 520 bytes; for the 10TB drives: 4160 bytes. Unless you reformat them back down to standard sector sizes, they won't work regardless of what firmware you have on them.

So, back to the point, it would appear from testing that the 10TB drives I now have access to all just work when formatted back down to 4096-byte sector sizes. I have done full tests with the f3 https://github.com/AltraMayor/f3. Yes, it's designed to find fake flash drives, but it's also a good way to test whether you can write to the entire drive and read back what you wrote. So simply reformatting the DKR2H-H10RSS drives to a 4096-sector size will likely work for you.

The only potential sticking point is that I have seen a single reference on the ServeTheHome forums suggesting that drives that only accept SCSI WRITE AND VERIFY commands have not been properly "exported" from the VSP. How true this is, I don't know, and talking to the people at work, they didn't do anything special in decommissioning the system, and simply reformatting the drives, and they are good to go.

I have not experimented with flashing different firmware on the 10TB drives, as reformatting gets them working for my use case: hundreds of drives in JBODs for disk-to-disk backup of a large GPFS file system using TSM.

Turned out that while reformatting the drives worked they worked, if they lost power at any point there reverted to only accepting SCSI_WRITE_AND_VERIFY commands.

The solution is to set bit 1 of byte 0x14 in mode page 0x38. You have to read in the current mode page, set the bit and write it out again as this mode page appears to vary from drive to drive. I can confirm setting the bit works in enabling a wide range of drives pulled from VSP systems, assuming you have also reformatted them to a standard 512/4096 byte sector size as appropriate for the drive. It has basically worked in every model of drive I have tried it on, which is about 10 from memory now.

On a related note, I also got access to a bunch of 7.68TB SAS SSD's from a VSP. Simply reformatting these to a standard sector size absolutely worked in getting them functioning permanently. My guess is either they don't support the SCSI_WRITE_AND_VERIFY command so cannot be locked down in the first place or the drive vendors told the VSP designers to take a running jump when asked to make it a feature on drives shipped to them.

jabuzzard, This, Too, Shall Pass (c) I mean your illusions that you are able to control Page 0x38 HGST Firmware. You can control all scenarios of its change, right? Really?

The following blog investigates the write lock issue and restores the generic factory version of mode page 0x38:

https://blog.csdn.net/chinahyn/article/details/159700008

The author did not determine which bit was responsible for the lock, so he replaced the entire mode page.

My translation and summary:

https://www.hddoracle.com/viewtopic.php?p=25382#p25382

_________________
A backup a day keeps DR away.