Thursday, February 14, 2008

Making a Hitachi DKR2D-J72FC work in a Sun Blade 1000 workstation

I thought I'd post my experiences in the hope that it helps someone.

I recently purchased a Hitachi DKR2D-J72FC off ebay that shows internally as a DKR1C-J72FC with a firmware revision of D2W4 for use in a Sun Blade 1000 workstation with a Qlogic 2200 FC controller. According to the seller, the drive came from a StorEdge array that was used with AIX so the drive was formatted with a block size of 520 and would require low level formatting to a block size of 512.

The first step in getting this drive to work involved setting a jumper on pins 13 & 14 so the drive would autospin. This allows the Sun Blade 1000 to actually see the drive. However, even though Solaris could see the drive, the Solaris format utility was unable to format/label the drive.

I solved the format problem by downloading and compiling sg3_utils and used the sg_format program which has a convenient parameter for the block size to low-level format the drive to a 512-byte block size. After that, despite the fact that Solaris could see the drive and could see it was formatted to a 512-byte block size the Solaris format utility was still unable to write a partition table/label (e.g: error writing VTOC error) to the drive.

After several days, I finally stumbled upon a solution and it is nothing short of bizarre. For whatever reason this drive refuses to allow writes to it unless the write cache bit has been enabled. As the Solaris format utility is unable to change this parameter, I downloaded and compiled another tool called sdparm and used the following command to enable the write cache:
sdparm --set=WCE=1 /dev/rdsk/[device]s0

After enabling the write cache, the Solaris format utility was immediately able to write a label to the drive and I was able to create a filesystem and mount it. The drive passes all read/write surface tests I've thrown at it and works normally as long as the write cache bit remains enabled. If I disable the write cache it will immediately revert to the old behavior where any attempt to write to the drive results in an I/O error.

It's almost like the firmware on the drive is using that flag as some sort of global write-protection flag. This is really strange but since I don't require 100% data integrity I can live with the write cache being enabled. I hope this information helps anyone else that might be struggling trying to get one of these drives to work.

19 comments:

Anonymous said...

Thanks, your post has been quite informative - I'm dealing with similar drives. Could you post the results of

sdparm --all /dev/rdsk/[device]s0

After setting WCE=1, my drives seem to hang when I attempt to write anything (including label).

alyandon said...

Sure. I've uploaded the results to http://www.exgenesis.com/sdparm-all.txt

Anonymous said...

I'm VERY happy to come across this, since I've got three of these drives sitting on my desk next to me, and my Blade 2000 behind me with its pitiful 36G internal disk.

I have a stupid question, though... which pins are 13 and 14? With the drive electronics facing up and the jumper block facing me?

I'm embarrassed to even have to ask that.

alyandon said...

I've uploaded the instructions given to me by the eBay reseller for my specific drive model which clearly shows which pins to jumper. It is very easy to do but for obvious reasons I can't take responsibility if you damage your drive (not that I can imagine that you really could damage a FC drive by jumpering the wrong set pins).

http://www.exgenesis.com/Hitachi-DKR2D-J72FC-autospin.pdf

Unknown said...

Hi,
I have a HITACHI DKR2D-J72FC model, with the format of solaris 10 I see "HITACHI-DKR1C-J072FC-D7W6", after format in 512 byte sector with the tool "scu" and after change write cache bit in 1 with "sdparm --set-WCE=1 /dev/rdsk/c2t1d0s0" I can't write VTOC from "format" command.
After this step the disk go in power-off state and is requires a system power-off/on for check the HDD.
Is there a way for writing VTOC in this FC HDD?
thanks

alyandon said...

Sorry Matteo, since you are using a different revision firmware for the drive I don't have any suggestions.

If the drive is completely powering down on its own that might indicate some sort of hardware issue.

Anonymous said...

Not sure if you are still tracking this blog, but the SG3_UTILS you reference - I can only find for Linux, and not Solaris 10. Same with sdparm. I know you said you compiled them on Solaris. I can figure that out, but want to know if you are talking the Linux based tools that you just compiled on Solaris, or did you actually find a copy for Solaris? I have Google searched till my fingers hurt and cant seem to find any.

Thanks for writing this up. I have two of these drives and would love to be able to use them.

alyandon said...

The source code for those utilities should compile under Solaris just fine. You'll need to have either gcc or Sun Studio installed to compile them.

Anonymous said...

Thank you. I will give that a shot.

Cheers.

Anonymous said...

I was able to compile on Solaris. Easy. Thanks for the tip. Question for you - does your write cache enable change back to "no" on reboot or for any other reason? This worked great, but today when I booted I got an error that the disk was bad but after re-running the sdparm command it started working. Wondering if you have this issue and if so, how you solved it. I use the disk for storage so running the sdparm when and then manually mounting the disk after boot isn't an issue it just seems strange that it would "revert" for no reason. Thanks again for your blog! It really helped me out.

alyandon said...

I could have sworn that I didn't need to do anything in order to get the WCE setting to persist.

However, checking the sdparm man page it looks like their is a "-S/--save" option that will do what you need.

Unknown said...

Hi, can you tell us where to download the sg3_utils for solaris? Also where to download sdparm for solaris? I am new to this, please help.

Thanks

Unknown said...
This comment has been removed by a blog administrator.
alyandon said...

You'll have to download the package in source form and compile it yourself.

http://sg.danny.cz/sg/sg3_utils.html - sdparm is part of the sg3_utils package.

If the latest versions don't want to build try using some of the older versions. I don't have a Solaris box handy anymore so I don't recall the particular version I used.

Anonymous said...

Hi, My hard drive can be see using probe-scsi-all under open boot, but can not be seen under "format". Do you think this is because the block size is 520?

Thanks

alyandon said...

I seem to recall that the Solaris format utility would see the drive but not be able to format it to 512 bytes blocks. That's why I had to use the sg_format utilty to do the low level format.

Anonymous said...

THANK YOU for this post! I've had a stack of the very same drives sitting around gathering dust for years, having tried and failed to format them up on my NetApp (which can use 520-byte blocks) and on a Sun 280R.

I recently rescued a loaded E3500 with a bunch of free disk slots and figured, "what the heck?" Stumbling across this post after an hour of Googling was a bit miraculous - but the solution you came up worked perfectly. I've now got half a dozen of those drives humming away in my E3500, a nice little ZFS sandbox... albeit a little expensive to run continuously at 1400 watts... ;-)

Cheers!

alyandon said...

Thanks! Glad to know some people are still benefiting from this post after all this time!

Anonymous said...

I mess around with vintage computers and these drives are just right for an old novell server except the block-size. After reading this post I am glad there is even a small possibility of getting them working.

thanks!
vk2hmc