Hello, I have been trying to convert my IBM disks from 528 bytes to 512 for 4 years. I will tell you my experiences in these 4 years. I hope I can guide someone and solve this problem. You have seen 528/520 to 512 problems on many forum sites. I have always succeeded in converting different brands of drives other than IBM to 512. But IBM disks shortened my life by at least 10 years.
Methods I tried (Methods I encountered in the forum)
setblocksize (tried didnt work)
sedutil (tried didnt work)
sudo sg_format --format -v --size=4096 (I tried, it didn't work)
sg_format -F -F -F (I tried, it didn't work)
"A friend's comment on my post is very important, please read it."
"`Oh hey, I have this exact same drive, and exact same issue! I haven't been able to solve this yet, but maybe putting what I've tried to do on the internet might help someone actually solve it? If they do, I really hope they post it in a public place.
This SSD really is a piece of work. It's a Seagate Nytro 3131 Read Intensive 7.68TB SED SSD that's been rebranded to an IBM 3.84TB SED SSD. Not only is the firmware modified to show all the fancy IBM stuff, but the drive size has been cleaved in half for whatever reason (my current guess is so they could sell 3.84TB drives when the real ones ran out of stock?) and it being an SED absolutely doesn't help.
What I tried on Ubuntu 22.04 running on an IBM Slicestor 2448 chassis (intel x86, probably just rebranded SuperMicro?): While sg_format with --size=528 works, or at least doesn't error, other sizes (like 512, 4096, and even 4224) will fail with the Invalid field in parameter list error I've grown to despise. I even ended up going through the SCSI command spec (the SeaGate
one) to figure out if sg_format was sending incorrect commands, but even my manual attempts via sg_raw ran into that error. I'm going to guess that IBM's custom firmware doesn't follow the spec when you try to change the block size, and they have custom data fields that must be provided. Or perhaps it's actually the right format, but IBM is having the drive throw a bogus error because proprietary reasons.
I should probably mention that I'm not new to reformatting block sizes. The previous IBM drives I've gotten in with non-512 block sizes have all formatted fine to 512 via sg_format, but IBM-branded SSD's, especially the SED ones, reject being converted. All of the IBM HDD's I've gotten have converted fine, and even some SSD's (though not SED SSD's).
sedutil-cli can handle the SED portion of the drive fine. The standard PSID reset works fine, I can take ownership of the drive and the mess with the locking ranges, all that works as standard. Trying to do any of the sg_format stuff while the drive is locked will correctly throw errors that point to the drive being locked. Trying to do the sg_format stuff with the drive freshly PSID-reset or unlocked will result in the Invalid field in parameter list crap, so it doesn't look like the SED stuff is actually getting in the way. SeaChest, Seagates own utility for this stuff, doesn't seem to be able to handle the drive either. While SeaChest Format seems to recognize the drive, displaying some information and showing that it should be able to do 512, 520, and 528 sector sizes, all of my attempts to use SeaChest Format to reformat the drive to 512 have failed, seemingly running into the same Invalid field in parameter list error from the sg_* commands.
One of the things I found referenced in the IBM docs that is supposed to be able to change an "Advanced Function" disk into a JBOD disk is iprconfig, the IBM Power RAID Configuration utility. There's even a github repo
for it that I was able to grab, compile, and install. Unfortunately, likely due to the Slicestor not actually having a RAID card (seems to just be an HBA) let alone an IBM one, while iprconfig will launch fine it wont actually detect any RAID cards or the drive. Most of this you can find online on existing discussions if you look hard enough though, so not much of this is new info, but it is compiled here. Now to what else I've done that I haven't been able to find online at all: Using actual non-rebranded IBM hardware.
I managed to get my hands on an IBM Power8 8247-21L/S812L server and got it to boot AIX Diag 7.2 to try to have the AIX Diagnostics reformat it to JBOD/512. Unfortunately, the drive never showed up in AIX. I took the 2 HDD's that were in it, put them in a RAID 0, and installed the PowerPC version of SUSE Linux Enterprise 15 via the power of the free trial and got iprconfig running on there. This time, on the actual IBM hardware, iprconfig DID recognize the RAID card and was able to see the 2 drives I put in the RAID 0 for SUSE, but still wasn't able to see the SED SSD. After some more testing, it seems like it can't see any SSD's? Not sure if it's my setup or if the RAID card is just wack.
I proceeded to get my hands on an IBM Power9 9008-22L/L922 server, which actually came with 2 U.2 SAS 4224 block sized SSD's (not SED though), and popped the 2 RAID 0 SUSE HDD's and the SED SSD in there. Got SUSE up and running, ran iprconfig, and though the SSD was labeled "R/W Protected", it was able to see it! Unfortunately, I wasn't able to reformat it to 512. Based on the logs, it seems iprconfig was also running into the same issues as sg_format. iprconfig also wasn't able to make a single-drive RAID 0 from the drive, and just errored (TODO: Try again from SUSE and put error in here). Putting the drive back into my Ubuntu box and using sedutil-cli to take ownership, make a locking range that spans the entire drive, and having the locking range unlocked by default, and putting the drive back into the Power9 box made it stop showing up as "R/W Protected" and allowed me to create the RAID 0.
Putting the drive into my Ubuntu box, PSID-resetting the drive, putting it back into the Power9 box, and booting into AIX 7.2 it showed the drive but errored when trying to format it for JBOD/512. The drive was listed as "R/W Protected", but doing a general reformat (keeps the block size) that AIX offers not only worked, but changed the state of it to "zeroed". Booting into SUSE, I was able to use iprconfig to make it into a RAID 0, so that was neat.
In SUSE, the various /dev/sg*'s will point to the actual drives even if they are in a RAID. For me right now, /dev/sg1 and sg2 are pointing to the two 283 GB drives that are in the RAID 0 housing SUSE, and sg3 is the SSD SED. Very interestingly, smartctl in SUSE will show the SSD as having a logical block size of 512, though it wont mention the physical block size. Running sudo smartctl --test=short /dev/sg3 wont error, but doesn't seem to actually work. I ran a single short test a while ago, and I can see that in the SMART Self-test log on SUSE, but no new tests I try to run are added to that log. Starting a long test then cancelling it via sudo smartctl --test=long /dev/sg3 and sudo smartctl -X /dev/sg3 still wont error, but no cancelled test shows up in the log. Running sudo sg_readcap /dev/sg3 will show a logical block size of 512, Logical blocks per physical block exponent=0, and both lbpme=0 and lbprz=0, despite Ubuntu saying otherwise (both are set to 1). Running
Weirdly, after running the smartctl stuff just now, it allowed me to do the sg_format with --size=512. Unfortunately, removing it and checking in Ubuntu shows that it's still 528/4224 block size. It also doesn't show any of the (cancelled) SMART tests I ran on SUSE but I can run a test from Ubuntu and it does show up in the SMART log. The IBM RAID card doesn't seem to actually relay any of the test requests to the drive.
Another message: "
You might want to read this:
https://hddoracle.com/viewtopic.php?f=59&t=3279
https://hddoracle.com/viewtopic.php?f=59&t=3280
These disks have software locks, it's all in the firmware on the disk. I tried more or less some brutal methods, changing firmware-parts, but killed some disks on the way.
You don't need special hardware, a regular SAS2/SAS3 HBA with IT-firmware that can talk directly to the disk is enough.
I also have no solution, but narrowed it a bit down. If partitcular 3rd vendor firmware has locks (no other sector size than 520 (SSD should have 4096) or no write without verify), you must change the whole firmware to generic.
You need to send some magic unlock code(s?) to the disk, then a secure erase, quick format and whole firmware with mode14 (then a power on/off reset/camcontrol stop/start). In a way similar to the sbr change on a HBA ( https://marcan.st/2016/05/crossflashing-the-fujitsu-d2607/ )
I am just not sure about the sequence order and the magic codes. I found out the protection stuff for SCSI/SAS began somewhere in 2005 and upwards , it is documented at t10.org, but there are too many files.
More info is spread over config files in niagara, I just can't put it together. You need to combine the info found in the readable config files over different niagara versions, then it all narrows down to regular scsi/sas commands.
In the links hddoracle you'll find videos of baking firmware with expensive software, but that is only needed to crossflash with mode5 and mode7 directly.
The important things: quick format, secure erase and/or start/stop a special smart-test gives a small time window, where the disk accepts more or THE magic codes.
I just can't put it together."
Many people said that this friend :
could solve the problem for money. I sent an e-mail to guy, but he said he had the disks I had and couldn't help.
The company sells the same disks I have on ebay and the TITLE says "FOR IBM DS8880". ebay link
This company is not a small business. I contacted this company and they said there is a way to convert these disks to 512 but there is a risk of bricking during converting.
These drives are manufactured by Seagate for IBM. you can see from here
Anyway, guys, my wife and I started to fight constantly because of these discs. If I can't solve this problem soon, I'm going to throw them away. It makes my wife very angry that I spend 3-4 hours on these discs every weekend. (150 discs in total, 3.8TB, 7.6TB, 15.3TB)
Methods I tried (Methods I encountered in the forum)
setblocksize (tried didnt work)
sedutil (tried didnt work)
sudo sg_format --format -v --size=4096 (I tried, it didn't work)
sg_format -F -F -F (I tried, it didn't work)
"A friend's comment on my post is very important, please read it."
"`Oh hey, I have this exact same drive, and exact same issue! I haven't been able to solve this yet, but maybe putting what I've tried to do on the internet might help someone actually solve it? If they do, I really hope they post it in a public place.
This SSD really is a piece of work. It's a Seagate Nytro 3131 Read Intensive 7.68TB SED SSD that's been rebranded to an IBM 3.84TB SED SSD. Not only is the firmware modified to show all the fancy IBM stuff, but the drive size has been cleaved in half for whatever reason (my current guess is so they could sell 3.84TB drives when the real ones ran out of stock?) and it being an SED absolutely doesn't help.
What I tried on Ubuntu 22.04 running on an IBM Slicestor 2448 chassis (intel x86, probably just rebranded SuperMicro?): While sg_format with --size=528 works, or at least doesn't error, other sizes (like 512, 4096, and even 4224) will fail with the Invalid field in parameter list error I've grown to despise. I even ended up going through the SCSI command spec (the SeaGate
one) to figure out if sg_format was sending incorrect commands, but even my manual attempts via sg_raw ran into that error. I'm going to guess that IBM's custom firmware doesn't follow the spec when you try to change the block size, and they have custom data fields that must be provided. Or perhaps it's actually the right format, but IBM is having the drive throw a bogus error because proprietary reasons.
This was the command I have in my notes, I think this is the correct one? It's been a bit since I've worked on this. I do recall that using \x02\x10 (528) instead of \x02\x00 (512) worked, which aligns with sg_format with --size=528 working but --size=512 not.
I should probably mention that I'm not new to reformatting block sizes. The previous IBM drives I've gotten in with non-512 block sizes have all formatted fine to 512 via sg_format, but IBM-branded SSD's, especially the SED ones, reject being converted. All of the IBM HDD's I've gotten have converted fine, and even some SSD's (though not SED SSD's).
sedutil-cli can handle the SED portion of the drive fine. The standard PSID reset works fine, I can take ownership of the drive and the mess with the locking ranges, all that works as standard. Trying to do any of the sg_format stuff while the drive is locked will correctly throw errors that point to the drive being locked. Trying to do the sg_format stuff with the drive freshly PSID-reset or unlocked will result in the Invalid field in parameter list crap, so it doesn't look like the SED stuff is actually getting in the way. SeaChest, Seagates own utility for this stuff, doesn't seem to be able to handle the drive either. While SeaChest Format seems to recognize the drive, displaying some information and showing that it should be able to do 512, 520, and 528 sector sizes, all of my attempts to use SeaChest Format to reformat the drive to 512 have failed, seemingly running into the same Invalid field in parameter list error from the sg_* commands.
One of the things I found referenced in the IBM docs that is supposed to be able to change an "Advanced Function" disk into a JBOD disk is iprconfig, the IBM Power RAID Configuration utility. There's even a github repo
for it that I was able to grab, compile, and install. Unfortunately, likely due to the Slicestor not actually having a RAID card (seems to just be an HBA) let alone an IBM one, while iprconfig will launch fine it wont actually detect any RAID cards or the drive. Most of this you can find online on existing discussions if you look hard enough though, so not much of this is new info, but it is compiled here. Now to what else I've done that I haven't been able to find online at all: Using actual non-rebranded IBM hardware.
I managed to get my hands on an IBM Power8 8247-21L/S812L server and got it to boot AIX Diag 7.2 to try to have the AIX Diagnostics reformat it to JBOD/512. Unfortunately, the drive never showed up in AIX. I took the 2 HDD's that were in it, put them in a RAID 0, and installed the PowerPC version of SUSE Linux Enterprise 15 via the power of the free trial and got iprconfig running on there. This time, on the actual IBM hardware, iprconfig DID recognize the RAID card and was able to see the 2 drives I put in the RAID 0 for SUSE, but still wasn't able to see the SED SSD. After some more testing, it seems like it can't see any SSD's? Not sure if it's my setup or if the RAID card is just wack.
I proceeded to get my hands on an IBM Power9 9008-22L/L922 server, which actually came with 2 U.2 SAS 4224 block sized SSD's (not SED though), and popped the 2 RAID 0 SUSE HDD's and the SED SSD in there. Got SUSE up and running, ran iprconfig, and though the SSD was labeled "R/W Protected", it was able to see it! Unfortunately, I wasn't able to reformat it to 512. Based on the logs, it seems iprconfig was also running into the same issues as sg_format. iprconfig also wasn't able to make a single-drive RAID 0 from the drive, and just errored (TODO: Try again from SUSE and put error in here). Putting the drive back into my Ubuntu box and using sedutil-cli to take ownership, make a locking range that spans the entire drive, and having the locking range unlocked by default, and putting the drive back into the Power9 box made it stop showing up as "R/W Protected" and allowed me to create the RAID 0.
Putting the drive into my Ubuntu box, PSID-resetting the drive, putting it back into the Power9 box, and booting into AIX 7.2 it showed the drive but errored when trying to format it for JBOD/512. The drive was listed as "R/W Protected", but doing a general reformat (keeps the block size) that AIX offers not only worked, but changed the state of it to "zeroed". Booting into SUSE, I was able to use iprconfig to make it into a RAID 0, so that was neat.
In SUSE, the various /dev/sg*'s will point to the actual drives even if they are in a RAID. For me right now, /dev/sg1 and sg2 are pointing to the two 283 GB drives that are in the RAID 0 housing SUSE, and sg3 is the SSD SED. Very interestingly, smartctl in SUSE will show the SSD as having a logical block size of 512, though it wont mention the physical block size. Running sudo smartctl --test=short /dev/sg3 wont error, but doesn't seem to actually work. I ran a single short test a while ago, and I can see that in the SMART Self-test log on SUSE, but no new tests I try to run are added to that log. Starting a long test then cancelling it via sudo smartctl --test=long /dev/sg3 and sudo smartctl -X /dev/sg3 still wont error, but no cancelled test shows up in the log. Running sudo sg_readcap /dev/sg3 will show a logical block size of 512, Logical blocks per physical block exponent=0, and both lbpme=0 and lbprz=0, despite Ubuntu saying otherwise (both are set to 1). Running
yields a different error, "MODE SELECT command: Transport Error". I'm going to guess that the IBM RAID card is not providing direct communication to the drive, and shows a false version of the drive.
Weirdly, after running the smartctl stuff just now, it allowed me to do the sg_format with --size=512. Unfortunately, removing it and checking in Ubuntu shows that it's still 528/4224 block size. It also doesn't show any of the (cancelled) SMART tests I ran on SUSE but I can run a test from Ubuntu and it does show up in the SMART log. The IBM RAID card doesn't seem to actually relay any of the test requests to the drive.
Another message: "
You might want to read this:
https://hddoracle.com/viewtopic.php?f=59&t=3279
https://hddoracle.com/viewtopic.php?f=59&t=3280
These disks have software locks, it's all in the firmware on the disk. I tried more or less some brutal methods, changing firmware-parts, but killed some disks on the way.
You don't need special hardware, a regular SAS2/SAS3 HBA with IT-firmware that can talk directly to the disk is enough.
I also have no solution, but narrowed it a bit down. If partitcular 3rd vendor firmware has locks (no other sector size than 520 (SSD should have 4096) or no write without verify), you must change the whole firmware to generic.
You need to send some magic unlock code(s?) to the disk, then a secure erase, quick format and whole firmware with mode14 (then a power on/off reset/camcontrol stop/start). In a way similar to the sbr change on a HBA ( https://marcan.st/2016/05/crossflashing-the-fujitsu-d2607/ )
I am just not sure about the sequence order and the magic codes. I found out the protection stuff for SCSI/SAS began somewhere in 2005 and upwards , it is documented at t10.org, but there are too many files.
More info is spread over config files in niagara, I just can't put it together. You need to combine the info found in the readable config files over different niagara versions, then it all narrows down to regular scsi/sas commands.
In the links hddoracle you'll find videos of baking firmware with expensive software, but that is only needed to crossflash with mode5 and mode7 directly.
The important things: quick format, secure erase and/or start/stop a special smart-test gives a small time window, where the disk accepts more or THE magic codes.
I just can't put it together."
Many people said that this friend :
could solve the problem for money. I sent an e-mail to guy, but he said he had the disks I had and couldn't help.
The company sells the same disks I have on ebay and the TITLE says "FOR IBM DS8880". ebay link
This company is not a small business. I contacted this company and they said there is a way to convert these disks to 512 but there is a risk of bricking during converting.
These drives are manufactured by Seagate for IBM. you can see from here
Anyway, guys, my wife and I started to fight constantly because of these discs. If I can't solve this problem soon, I'm going to throw them away. It makes my wife very angry that I spend 3-4 hours on these discs every weekend. (150 discs in total, 3.8TB, 7.6TB, 15.3TB)
. (I know they can't convert to 512, I just wanted the disks away from me)