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.

Absolutely, I have done it on all nine different models of Seagate and HGST SAS spinning disks that I have access to. It was worked on them all. I have been away for the last 10 days with limited access, but a script that will flip all the bits on all the drives on your system is nearly finished testing. It also has an option to reformat all the drives connected to your system to the appropriate block size in parallel. I anticipate putting the release out at the weekend.

On SSD's I had access to two different models of SAS 7.68TB drives (Samsung and Toshiba) and on these simply reformatting to a block size of 4096 bytes was enough to get them working.

Here is the writeup and scripts that I have been using to process VSP drives. I used the script to fiddle with mode page 0x38 on nine or ten different models that still had the VSP firmware and were still write locked, and they all now work. This survives a power reset. The script will also format the drives down to 512/4096 physical block size as appropriate, individually in a screen in parallel so 100 drives take the same time as one.

https://github.com/digitalcabbage/vspenable

The actual fiddling with the mode page takes a few seconds per drive, the reformat takes hours.

I would note that replacing the entire mode page is probably a very bad idea. Even on the same drive model taken from the same VSP the mode pages are all different. The only safe approach is to set the LSB in byte 0x14 leaving everything else the same.

Interesting that some servers use weird sectors but I have not seen that much with disks I have seen. Most be from some large system that had thousands of disks in use.

SAS disks have poor resale as most can't figure out the right type of cable/enclosure. SATA 600 speed is quit adequate for hard disk speeds. I tried a USB SATA cable on one small SAS disk and it did not like it so don't but them for my storage needs.

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

Nothing weird about the sizes. Sector sizes of 520 and 528 bytes on disks is many decades old, and predate SATA and SAS by over a decade. They are used to hold the Data Integrity Field (a ECC of the data) on the drive for each sector. You then use DIX so this flows from the CPU through the HBA to the drive and back. Think of it a ZFS checksumming but done at much lower level so basically any file system you choose gets the protection and you don't have to burn so many CPU cycles to achieve it. It is only really implemented in high end storage arrays, though it is an "experimental" feature in various versions of RHEL.

A SAS disk will need a special active adaptor to run on a SATA interface. Just because they share the same connector does not mean the electrical signalling is the same. Historically they didn't exist, they do now, including ones that convert to USB3

https://www.amazon.co.uk/dp/B0G26DY51Q