HGST HUS723020ALS640 firmware cross-flashing

[SubnetMask]

I just got a few more HUS723020ALS640 HDDs to fill up my FreeNAS and hopefully get things running good. They passed my BadBlocks testing best I can tell (no errors reported, no reallocated sectors, no uncorrected errors), so I'd like to put them in play and re-create my VVol and do more testing. The only problem is my selective OCD. They are SAS disks, but the backplane LED behavior is that of SATA disks - off when idle and flash when active. There is an almost four year old bulletin (H206663) indicating that a fix was identified but was in the process of being developed. Apparently their latest firmware, 'J3K7', still doesn't correct this as I was able to get their utility to flash them when I had them in an old x3650 (first gen) server, and the behavior is the same as with the firmware that came on them.

The other seven drives I have are HUS723020ALS640's out of a EMC/Clarion SAN. The problem with these (That can be 'worked round' in a fashion) is that apparently, when I set the writeback cache to 'on' using smartctl, it isn't persistent across reboots, and as pointed out, possibly even across bus resets. What I found (by accident) with these 'IBM' drives is that when I set the writeback cache to enable (it was disabled when I received them), it seems to persist across reboots.

Now, I find it really hard to imagine that HGST (Or any other manufacturer) would have a totally separate assembly line making totally different drives for OEMs like Dell and IBM that they slap the same HGST model number on. It seems far more likely that they'd have one or more lines making 'HUS723020ALS640' drives, and that at the end of the assembly line, some drives would get HGST firmware, some would get Dell/EMC firmware, some would get IBM firmware, etc.

That being said, if it could be 'forced', I suspect that flashing HGST's latest firmware for the 'HUS723020ALS640' onto either of these drives would result in a properly functioning drive because, like I said, I have a hard time believing that a 'Dell' 'HUS723020ALS640' is in any way physically or electrically different from an 'IBM' 'HUS723020ALS640', and that neither of those are physically or electrically different from a 'HGST' 'HUS723020ALS640'. So that being said, is anyone aware of a way to 'force' drives to take the HGST firmware (which I haven't even been able to find 'in the wild')? Even if someone knows of a 'likely but not guaranteed' way to do it, I'd be willing to tempt fate with a drive to see if it worked. Some might say that such a thing may be able to allow people to flash HGST drives (for example) with firmware that'll allow an EMC or Equallogic (for example) to be happy with the drives - maybe - but at the same time, if the way involved meant modifying the firmware file so that model information matched (The EMC drives are reported as something like 'HUS7230CLAR2000', even though the sticker clearly has 'HUS723020ALS640' on it), I can't see how that would be an issue - if you modify the Dell firmware (for example) look for 'HUS723020ALS640' so it'll flash, it'll still report as a 'HUS723020ALS640' drive, not the Dell P/N, and would likely suffer the same compatibility issues as if it was running bone stock HGST firmware.

 

[styno]

Although your reasoning makes perfect sense to me, that is quite a big, deep and nasty rabbit hole you are diving into. You'll never know how the disks will behave in the long run if the modifications will work at all.
If you have the spare disks and are brave enough you can try to mess them up with something like HDDSuperTool, but I would first seek advice from some professionals that are working with those disks and their firmwares on a daily basis. A good start would be the hddoracle/hddguru forums (not sure if I can/should link them here).

 

[tvsjr]

This seems like a great way to turn expensive drives into bricks. I had some drives with the same issue on the write cache, and just added a simple boot script to enable them every time. Never had a problem. As for the blinky lights... meh.

 

[SubnetMask]

This seems like a great way to turn expensive drives into bricks. I had some drives with the same issue on the write cache, and just added a simple boot script to enable them every time. Never had a problem. As for the blinky lights... meh.

Well, these drives only cost $35 each, so not THAT expensive. I can't say I'd be totally heartbroken if I were to take one to try messing with it and lost it. Now if we were talking about a $400 drive, that would be much different.

As far as your script, yes, I saw that and may implement it (although to be honest, I don't understand how it works - running smartctl to enable it makes sense, but what's in the script doesn't make a lot of sense to me as to how it enables it), however, oddly, with my disks, with all the testing I've done, while there WAS a significant difference running Badblocks, there doesn't seem to be a significant difference in 'real world' performance - in fact with it off, write performance seems to be a tad higher and more consistent, whereas with it enabled, it seems to jump around a lot more and the overall average seems to be lower. *Shrug*. The only problem with the script though is if a bus reset would in fact cause it to revert to 'off', then unless is was set up to run as a cron job every 30 minutes or something, you could potentially end up with it off for who knows how long.

 

[tvsjr]

You must learn the ways of the script, young grasshoppa!

for file in /dev/da? /dev/da??; do echo "WCE: 1" | camcontrol modepage $file -m 0x08 -e; done
Iterate through everything that matches "/dev/da?" and "/dev/da??" and store each in variable $file (basically, we're going to do this for every drive da0-da99, and each time we're going to put the path to the drive in variable $file)
For each iteration:
In modepage 0x08 of each drive (name stored in $file), set item WCE to 1.

I didn't do a dramatic amount of testing, but I did observe badblocks to be *massively* faster in my case.

 

[SubnetMask]

Lol yes, I'm not good at scripting or programming. Have tried to learn, but haven't found 'the key'. I guess 'Camcontrol' is an application that can do the same things as smartctl (at least as far as enabling/disabling features like the write cache)?

As far as the performance, you are absolutely correct with Badblocks. While I don't have any numbers since I was running it on a Ubuntu machine, thus no graphs to look at, the post that made me look at that and try turning it on indicated 8Mbps or MBps (not sure which but both are slow) with it off and 150MB/s with it on. I saw similar performance differences. Was at 550 or so hours on the first four disks and it was only part way the fourth write set. With it enabled, the second set of drives finished in like a day and a half. But oddly, 'real world' write speeds don't seem to be nearly so dramatically different.