ST6000NM0034 DKS2F-H6R0SS 7FA6

[mr44er]

Check out sdparm.
Show everything with details and explanation:

Code:

sdparm -a /dev/sdX --long

I am very, very curious if you have

Code:

[cha: y,

@WCE secion now for all of your disks.

Write cache off and save (-s=set,-S=Save)

Code:

sdparm -s WCE=0 -S /dev/sdX

Write cache on and save:

Code:

sdparm -s WCE=1 -S /dev/sdX

[ch33ta]

What differences have you found?

Code:

[0:0:0:0]    disk    SEAGATE  DKS2F-H6R0SS     7FA6  /dev/sdc   /dev/sg2
[0:0:1:0]    disk    SEAGATE  DKS2F-H6R0SS     7FA6  /dev/sdd   /dev/sg3
[0:0:2:0]    disk    SEAGATE  DKS2F-H6R0SS     7FA6  /dev/sdg   /dev/sg6
[0:0:3:0]    disk    SEAGATE  DKS2F-H6R0SS     7FA6  /dev/sdh   /dev/sg7
[5:0:0:0]    disk    ATA      Samsung SSD 870  3B6Q  /dev/sda   /dev/sg0
[6:0:0:0]    disk    ATA      Samsung SSD 870  3B6Q  /dev/sdb   /dev/sg1
[15:0:0:0]   disk    SEAGATE  DKS2F-H6R0SS     7FA6  /dev/sde   /dev/sg4
[15:0:1:0]   disk    SEAGATE  DKS2F-H6R0SS     7FA6  /dev/sdf   /dev/sg5
[15:0:2:0]   disk    SEAGATE  DKS2F-H6R0SS     7FA6  /dev/sdi   /dev/sg8
[15:0:3:0]   disk    SEAGATE  DKS2F-H6R0SS     7FA6  /dev/sdj   /dev/sg9

See attached. First 4 drives highlighted green (sg2-sg5) are the ones that work (allowed writing GPT and data), last 4 highlighted red (sg6-sg9) are the ones that throw write error. Out of 4 non-working ones 3 have Write Cache Enabled (I can disable it with smartctl but it is a volatile change: as soon as drive is pulled out, it goes back to enabled). So I believe most of the diffs are related to this option enabled. Each working - non-working pair uses separate sff cable between the backplane and HBA and I have 2 HBAs to eliminate any connectivity questions.

HOWEVER, there is one difference that matches the working - non-working pattern: Mode Page 0x38, line 0x14. I need to see if I can change it and if it helps.

BTW the thing that I find unusual is every drive has a different number of cylinders. Not sure if this is normal.

Hi,
Any chance someone could help with changing the mode Page 0x38, line 0x14 as mentioned above.
I'm not that experienced with sg_wr_mode and hex editing.
Also have a few disks laying around, same model, firmware and control page output;

Code:

root@temp:~# sg_modes -p 0x38 -c 1 /dev/sg1
    SEAGATE   DKS2F-H6R0SS      7FA6   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
  Mode data length=88, medium type=0x00, WP=0, DpoFua=1, longlba=0
  Block descriptor length=8
> Direct access device block descriptors:
   Density code=0x0
00     ff ff ff ff 00 00 02 00

>> page_code: 0x38, page_control: changeable
00     b8 46 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
10     ff 00 00 1b 01 00 00 00  ff ff ff ff ff ff ff ff
20     00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00
30     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
40     00 00 00 00 00 00 00 00

[Capelo]

Using this thread, I finally managed to format a Hitachi VSP 5560075-A / ST6000NM0034 drive from 520B to 512B and create a working partition.
I used an LSI 9211 controller flashed in IT mode and formatted the drive to 512B using sg3-utils — the process took about 20 hours.

Afterward, I tried to modify Mode Page 0x38, byte 0x14, as mentioned above, but the command didn’t go through.
Then I switched from the LSI 9211 to a Dell PERC H730. The controller recognized the formatted HDD but couldn’t create a partition.

I set all HDDs to JBOD mode, and only then was I able to successfully change Mode Page 0x38, byte 0x14.
I checked my Mode Page 0x38 dump using:
sudo sg_modes -p 0x38 /dev/sgX # mode page 0x38 dump
And change byte 0x14 (the 21st byte) from 00 to 01.
sudo sg_wr_mode --page=0x38 --contents="B8,46,00,02,00,03,74,08,00,00,00,02,BA,A0,F4,B0,02,00,00,12,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00" /dev/sda
Essentially, this changes 21st byte from 00 to 01.
After that, I was able to successfully create a partition.
Thank you to everyone in this thread for providing valuable information.

[Capelo]

Add -s to save.
sudo sg_wr_mode --page=0x38 --contents="B8,46,00,02,00,03,74,08,00,00,00,02,BA,A0,F4,B0,02,00,00,12,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00" -s /dev/sdX

[Hardcore Games]

I wonder if you are aware that the hard disks in this topic are SAS

[jabuzzard]

I am going to add that the information in this tread is very close to being complete.

What you need to do in general is set bit 1 of byte 0x14 in mode page 0x38 to make the drives usage on ordinary systems after reformatting to a normal physical 512/4096 block size as appropriate.

On a Seagate drive this would appear to be changing 0x00 to 0x01 as detailed here. However on an HGST drive this is changing 0x02 to 0x03. I have only seen Seagate and HGST drives from a VSP system. Well not strictly true I have a number of SAS, SSD but these just work when reformatted to a normal block size, no extra steps required. For spinning disks it is Seagate and HGST only.

I have verified that this works across a number of different drive models from both Seagate and HGST.

I have also deduced that the product ID returned by the drive tells you the manufacturer, the physical size rotational speed and the capacity of the drive. So take the model format of

DKX#@-YZZZSS

Then

X is R for HGST and S for Seagate drives

# is either a 5 for a 2.5" drive or 2 for a 3.5" drive

@ is an uppercase letter exact meaning unknown

Y is H for a 7200 RPM drive, J for a 10k RPM drive and K for a 15k RPM drive

ZZZ indicates the capacity of the drive. If it is three digits then the capacity is in GB. If there is an R it is a decimal point and the capacity is in TB

so some examples for the last second part after the dash

K300SS is a 15k RPM drive with a capacity of 300GB

J900SS is a 10k RPM drive with a capacity of 900GB

J1R2SS is a 10k RPM drive with a capacity of 1.2TB

H4R0SS is a 7200 RPM drive with a capacity of 4.0TB

H10RSS is a 7200 RPM drive with a capacity of 10TB

The @ uppercase letter seems to indicate a drive series and is increasing over time. That is newer drives have a higher letter in the alphabet. Presumably you need to use a lookup table to work out what they refer to.

[WebClaw]

We have done these VSP drives before.

Formatting them from 520 to 512 is only half the job. The drive can format correctly, report 512-byte sectors, and still refuse normal writes because the VSP configuration is still present in Mode Page 0x38.
The change is byte 0x14.

For the drives we have seen:
Seagate: 0x00 -> 0x01
HGST: 0x02 -> 0x03

So the actual change is simple:
byte_0x14 |= 0x01;
That is bit 0, not bit 1.

For HGST 0x02 becomes 0x03. Setting the byte directly to 0x01 would clear the existing 0x02 flag.

Read Mode Page 0x38 from the drive you are working on:
sg_modes -p 0x38 /dev/sgX

Check what is changeable:
sg_modes -p 0x38 -c 1 /dev/sgX
Change byte 0x14, write the page back, save it, power-cycle the drive, then verify it again.

The process is basically:
Format 520 -> 512.
Read Mode Page 0x38.
Set bit 0 of byte 0x14.
Write and save it.
Power-cycle.
Confirm normal read/write operation.

[WebClaw]

Without altering my initial post - One thing I should add.

sg_wr_mode supports a mask, so alter only bit 0 of byte 0x14 and leave the rest of the drive's mode page untouched.
sg_wr_mode --page=0x38 \
--contents=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1 \
--mask=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1 \
--save /dev/sgX
That changes only 0x14 & 0x01.

We have done these VSP drives before.

Formatting them from 520 to 512 is only half the job. The drive can format correctly, report 512-byte sectors, and still refuse normal writes because the VSP configuration is still present in Mode Page 0x38.
The change is byte 0x14.

For the drives we have seen:
Seagate: 0x00 -> 0x01
HGST: 0x02 -> 0x03

So the actual change is simple:
byte_0x14 |= 0x01;
That is bit 0, not bit 1.

For HGST 0x02 becomes 0x03. Setting the byte directly to 0x01 would clear the existing 0x02 flag.

Read Mode Page 0x38 from the drive you are working on:
sg_modes -p 0x38 /dev/sgX

Check what is changeable:
sg_modes -p 0x38 -c 1 /dev/sgX
Change byte 0x14, write the page back, save it, power-cycle the drive, then verify it again.

The process is basically:
Format 520 -> 512.
Read Mode Page 0x38.
Set bit 0 of byte 0x14.
Write and save it.
Power-cycle.
Confirm normal read/write operation.

[jabuzzard]

We have done these VSP drives before.
So the actual change is simple:
byte_0x14 |= 0x01;
That is bit 0, not bit 1.

I have seen that called both bit 1 and bit 0 over the years. I tend to call it bit one, so to be clear the least significant bit.

[pepe]

it is bit 0. as its value stands for 2 to the 0.
doN't call it bit1, that's not supportable from either mathematical or IT perspective.

[fzabkar]

In Data General's Nova and Eclipse minicomputers, bit 0 was the most significant bit.

[pepe]

that's also shit. mathematically it is shit. Programatically it is shit. So it is a shit example and you know that coz you are a lot smarter than bringing in a shit example. sorry.
we might talk about MSB first or LSB first in terms of communication, but bit0 IS LSB, with value of 2 to the 0. Period. Copyright BlackST
MSB can be whatever power of two the given system supports, but bit0 is always the LSB with positional value of 1. If someone wants to do it differently, he might, but that would lead to a whole load of misunderstanding, errors in code, etc. Is that worth ? Or could we agree that math is math everywhere and bit0 is bit0. Do we want to speak the same language or not. Things are much more simple if we do.
so please...

[fzabkar]

that's also shit. mathematically it is shit. Programatically it is shit. So it is a shit example and you know that coz you are a lot smarter than bringing in a shit example. :) sorry.
we might talk about MSB first or LSB first in terms of communication, but bit0 IS LSB, with value of 2 to the 0. Period. Copyright BlackST :)
MSB can be whatever power of two the given system supports, but bit0 is always the LSB with positional value of 1. If someone wants to do it differently, he might, but that would lead to a whole load of misunderstanding, errors in code, etc. Is that worth ? Or could we agree that math is math everywhere and bit0 is bit0. Do we want to speak the same language or not. Things are much more simple if we do.
so please... :beer:

No need to get upset.

I worked on that machine. Sure, I had to do some mental gymnastics, and I'm not saying it is a good system, but it existed. That's all I'm saying.

BTW, I hate little-endian. It also involves some mental gymnastics, but we've all learned to live with it.

Here is a write-up of one of my first data recoveries in the 1980s:

https://www.hddoracle.com/viewtopic.php?p=5729#p5729

You can see that I wrote a machine code utility using DG assembler. The number base was octal, as was the layout of the switches on the control panel.

See page 13:

Programmer's Reference Manual NOVA LINE COMPUTERS:

https://www.bitsavers.org/pdf/dg/015-000023-01_ProgRef_Sep75.pdf

In order to avoid confusion when talking about the information contained in bytes and words, the bits that make up these units of information are numbered from left to right, with the leftmost (high-order) bit always numbered bit 0. The numbering extends to the right and is always carried out in the decimal number system.

The rightmost (low-order) bit in a byte is bit 7.
The rightmost bit in a word is bit 15.

[pepe]

yeah, i accept there were glitches in engineering minds but let's not make it an example against a good practice.
LE, btw is very logical also, if you have to deal with large numbers on a lower word width cpu, it makes sense to deal with the LSB first, and to place that on lower mem address and loop thru all the bytes until you reach the MSB. It is only slightly difficult to read for a human eye but once you understand the purpose, it is perfectly fine.
I see no pros for BE, it can only be handled easily if your processor can load/store the whole word in one operation. Otherwise it is a pain. Or i am too biased

[fzabkar]

LE is a case of engineers expecting people to bend their brains to adapt to their hardware rather than engineers adapting their designs to accommodate human thinking processes. Then there is the RPN versus algebraic philosophy in calculators ...

[pepe]

i disagree on that one, for low level programming LE is logical, BE could only be done with some overhead having a negative impact on performance, so it makes sense for a programmer to bend his thinking in favor of performance. Of course, on higher level languages this is hidden from the programmer, so why bother?
I'm afraid if you tried to adapt hw to human thinking in this matter, the result would be more complicated and less effective. As such, one might try to build computers based on decimal system as that's closer to human thinking, but how efficient would that be?

[jabuzzard]

that's also shit. mathematically it is shit. Programatically it is shit. So it is a shit example and you know that coz you are a lot smarter than bringing in a shit example. sorry.
we might talk about MSB first or LSB first in terms of communication, but bit0 IS LSB, with value of 2 to the 0. Period. Copyright BlackST
MSB can be whatever power of two the given system supports, but bit0 is always the LSB with positional value of 1. If someone wants to do it differently, he might, but that would lead to a whole load of misunderstanding, errors in code, etc. Is that worth ? Or could we agree that math is math everywhere and bit0 is bit0. Do we want to speak the same language or not. Things are much more simple if we do.
so please...

45 years ago when I was been taught number bases which admittedly was mostly doing stuff in base 5 (why the hell they picked base 5 I have no idea) my mathematics text books called it bit one. I am also sure if he was still alive Wirth would like to have a word with you. Just because zero based indexing is the most common does not make it the only valid choice.

Anyway a Bash script to make turning a drive taken out of a VSP system simple with some other info the readme.

https://github.com/digitalcabbage/vspenable/