R730 with PERC H730 caps negotiated speed at 6Gbps

zeRusski,

Would you confirm a couple things for me?

What is the EMC part #?

What is the speed of the drive that is listed on the EMC label?

Did you change the firmware on the drive, if so with what process?

Let me know. 

Thanks.

Hi Chris. Thank you for reaching out.

I've not mucked with firmware at all since I've no clue where to even get it though I did look around a bit. Dell Lifecycle Controller update did not offer to update their firmware just the PERC H730. Not confident I'll be able to source anything latest even.

FWIW controller BIOS and Smartmontools show their firmware revision as C342 which I believe is or used to be some EMC convention.

Attached are pics of all p/n I could see anywhere on them. One of them is EMC.

Front label shows them as HUSMM1616ASS204 where IIRC in HGST that [S2] towards the end shows SAS interface i.e S6=6Gbps and mine S2=12Gbps.

Smartmontools id them as:

HITACHI HUSMM141CLAR1600 # Disk descr.
0SYBE15A # Disk ident.

Does that help?

The issue you're seeing, based on the part numbers, is that the drive is intended to be used in a Unity system, and not in a server. The Unity system is 6gbps so that is why you seeing it showing as such. With it not being supported in the server we can't attest to what the drive will do if used. My suggestion would be to find different drives.

Hope this helps.

Certainly, finding other drives is an option sadly not viable for me. I've already paid good money to fill the whole expander bay with them. I understand Dell can't give any guarantees and not liable should those drives misbehave but they are 12Gbps drives and they are HGST drives first with spec sheet and all and Unity drives second. And H730 is advertised as SAS-3 12Gbps that can even handle 520 phy sector drives (which they are even if I'm using 512byte logical blocks). Is there really no other option I could try with that PERC controller? I'll take the risk and responsibility.

Do you think I'd have more luck with a different controller e.g. LSI SAS 9300-8i that I linked to in the first post? Problem is that I've no idea if this or any other HBA would work with Dell's expander backplane. My guess is it would and then I will have thrown money at PERC for nothing. PERC controller is using LSI chip so I don't really see why it is having an issue here.

As it stands I'm losing at least half of IO performance for ... unknown reasons.

> The Unity system is 6gbps so that is why you seeing it showing as such. With it not being supported in the server we can't attest to what the drive will do if used.

I've re-read your comment and it just dawned on me that it makes IMO no sense at all for R730 to cap or limit the disk, cause that PERC card is fully capable of 12Gbps. I got confused by the choice of words to be honest. However, if Unity like you say can only do 6Gbps now it would want IO capped. So, let me read between the lines: best place to do this is at firmware level? Can I please please please change firmware on these drives back to HGST or smth that would appease PERC H730. I've no idea where to source that firmware though. I've not had any luck with Google.

Thank you again for taking the time to discuss this

By firmware I mean the firmware of the drives themselves is the limiting factor, not the controller. The controller is just showing what the drive is presenting, which is 6gbps speed capability.

right. That's exactly what I had in mind. Certainly drive firmware not controller. That's why I mentioned how I got confused by your reply there. I thought it implied that R730 was "trying to protect itself" when its actually the Unity. Well the question now is where to source suitable firmware sigh. I think these are OEM drives ... so big question where to even begin

Being Unity drives, and intended use being in 6gbps systems,  the speed is likely locked to 6gbps by the firmware. So to get past that you will probably need to start with addressing the firmware on the drives. 

I couldn't tell you if it would be different on the other controller, as it likely would still be limited due to the firmware. 

Is that our winner? https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=0gwy5

I've not been able to find any other firmware matching that model.

When I type in the Service Tag it says incompatible - weird seeing how R730 is listed in compatible systems bottom of the page.

Not entirely clear how to apply it though. Process described on that page all pointy-clicky. So what do I do in Linux console? I could boot off live USB or smth. Or perhaps I can feed it to Lifecycle Controller over the network and it'll know what to do?

Hi Marco. Thank you for picking this up.

iDrac refused to upload the BIN file saying it isn't supported format. Win .exe uploaded but showing:

Unable to complete the firmware update operation because the specified firmware image is for a component that is not in the target system inventory.

and wouldn't let me choose that package to try and install. 

Do I understand correctly that this .BIN file is a CLI executable that I should be able to run under Linux? Am about to try that next but these "magical compatibility" checks that DUP performs may prevent the reflash yet again. I'm probably getting ahead of myself here but is there no other way to extract and apply the firmware to that drive?  With half of IO perf at stake I'm willing to risk a single drive as guinea p. If it gets bricked its on me.

I'll go ahead and try the Linux path but will be keeping an eye on this thread.

Hello,

yes this firmware is the one for this model of drive.

For linux depending of the distro, you can use the package that you have on the link.

Thanks

Marco

Hi Marco or Chris.

Tried two approaches running the latest Fedora Live USB.

First without specifying actual device:

------------

$ sudo ./SAS-Drive_Firmware_0GWY5_LN_L384_A00.BIN -q -f -n
Collecting inventory...
...
Running validation...

This Update Package is not compatible with your system configuration.

--------------

Then tried to supply FQQD as it is shown in my iDraq 8 Hardware Inventory:

$ sudo ./SAS-Drive_Firmware_0GWY5_LN_L384_A00.BIN -q -f --selectiveupdate=Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1
[sudo] password for liveuser:
Collecting inventory...
...
Running validation...
Invalid FQDD has been passed in command line parameter. Exiting.

----------

Looks like even if I get the right FQQD somehow inventory validation will prevent me from flashing.

I then extracted the package contents with `--extract`. My guess is the actual firmware is that `payload/SPDLL384.fwh` file? Question is how to apply it manually and bypass the inventory validation?

FWIW I have been able to persuade Dell update package validator to at least attempt to push matching firmware to that drive. Achieved by hex-editing the .fwh file. It then attempts to "download" the firmware (having stripped the header from that file) onto the drive. Sadly debug.log shows some SCSI sense error which I do believe to be 0xA so probably copy error. But I couldn't decode the SCSI sense data. Maybe it is being logged with different endianness. Need knowledgeable low-level SCSI person to help with this or maybe Dell/EMC stuff could step in and lend a hand. My guess is EMC firmware did something funny to how that drive responds to SCSI commands