Yeah, it looks like there’s some more granularity required with sg_format's fastformat flag. The hugo tool from HGST works perfectly for the fast format though, lets you swap sector size in <15 seconds. I’ll upload some binaries later tonight.
Will you post a link to the tools?
Sorry about the delay.
Here’s a built version (64-bit) of 6.8.3, a Windows binary, and a newer version rpm package (can be installed with alien on dpkg systems).
1 Like
Thank you. I downloaded them.
Was there any progression with either HUGO on Unraid or a more comprehensive sg_format commandline?
I just got two H10 HGST drives and they both are 512 formatted with the protection bytes. I’m gonna use one of them as Parity and the other one as a replacement for an older drive that’s going into the “this will be another backup drive” farm, so it would be wise for me to do these formats beforehand, if they’re going to take 12 hours each 
Just coming back to say that, after I got a 4kn HBA SAS compatible (some people say it’s not necessary, but I wanted a 4kn capable HBA anyway, so I waited until I got one), I managed to do it on Hugo, quite quickly.
I did it by running a Ubuntu Live CD on my Unraid machine, which means I could then install the Hugo .DEB release (hugo-7.3.2.x86_64.deb). I did have to manually install the “libncurses5” package as well, but after that, Hugo ran on that LiveCD.
It identified all of my hard drives and I just told it to format the HGST ones (through a serial number), change the sector size and quick format it, which happened in around 15 seconds. The command line used was “hugo format -s DRIVE_SERIAL -b 4096 --fastformat”.
I just rebooted back in Unraid and they are being listed as 8TB. What I’m having problem is to format them - They’re both providing a “buffer error”:
“Buffer I/O error on dev sde1, logical block 512, async page read”
One of them stopped giving out that error after 3 reformats and a couple of reboots, but I can’t seem to fix the other one.
Will keep trying.
1 Like
It seems that formatting the hard drives with sg_format without the --ffmt=1 flag (by accident), control-c out of it, which makes the drive no longer be detected on the system, rebooting, formatting it again with -ffmt=1 flag rebuilds enough of the information that the drive now is writeable, mountable and apparently working perfectly?
How reliable would this filesystem be? Might just do a long sg_format overnight - I wish I just had done that in the first place
I got 6 12tb HGST drives in yesterday that had PI turned on. I ran format with sg_format and didn’t use the size flag to change it from 512 to 4096. I had 3 drives formatting at the same time and only realized this after the first one finished. I tried a resize after the long format completed but that would not show the correct size. I tried to use the fast format flag with option 1 to change it to 4k but it didn’t work. I tried it again with option 2 and it worked.
After my success with the first drive it got me wondering if this would work on the other 3 drives that I hadn’t touched yet. I pulled the first drive and popped another one in, ran the same command and boom it was done in about 30 seconds.
The 1st screenshot is from the first drive that I did a long format on. The 2nd screenshot is from the 4th drive that I did not do a long format on. I don’t know what the difference is between flag 1 and 2, maybe @Riggi knows more. These seems to have worked though.
This actually didnt appear to work (on HGST 8TB with Sun firmware). Doing full formats now.
Had to perform the same operation on some BitDeals 8TB drives that I recently acquired.
Had to run the following commands:
sg_format --format --ffmt=2 --size=4096 -v /dev/sdX
sg_readcap /dev/sXX
2 Likes
It’s been a while since I looked at this part of the SCSI command reference, but it is strange to me that --ffmt=2 works when --ffmt=1 fails - IIRC it’s a stricter policy for verification of formats, I didn’t even test it because of this, though I believe that implementation can and will vary between manufacturers. Glad you tried it! Should save folks lots of time.
@Riggi, @dwell and I spent the past 8+ hours attempting to get this to work. So far, looks like only the regular format option is working.
I tried to format 2 more drives yesterday using --ffmt=2 and it appeared to be successful but when I tried to format the drives in UD it said it formatted them but I couldn’t mount them. I checked the unraid log and both drives were showing error messages I’ve never seen before. It seems like this might not work after all. 
I ran a long format on them but I haven’t been able to test them yet to see if they work now.
@dwell had the exact same experience. It was resolved by doing a long format.
1 Like
I was able to format one of them in UD and mount it so the long format did fix it. I added both disks as parity and parity is rebuilding. No more errors in the unraid log either.
I need to go back and test the other drives I already formatted.
Just putting my reply here in case.
I ran the following commands on each drive to ensure they reported the correct size. Thanks to @SpamMeDeeper
sg_readcap /dev/sdX sg_format --format --size=4096 /dev/sdX sg_readcap /dev/sdX
–where X is the letter assigned in unRAID. I ran the readcap command after the finish to confirm the size was reporting correctly.
3 Likes
Followed these steps to get my drives updated but the format took less than a minute, not the hours it should have for an 8TB drive.
sg_readcap /dev/sdX
sg_format --format --size=4096 /dev/sdX
sg_readcap /dev/sdX
Still getting the same errors as everyone else. even after reboots, and running the format commands several times.
Jun 19 18:02:48 RivaUnraid kernel: blk_update_request: critical medium error, dev sdp, sector 4096 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jun 19 18:02:48 RivaUnraid kernel: Buffer I/O error on dev sdp, logical block 512, async page read
Any clue how to get these to run without the errors?
Little update on my HGST drives:
When I “sg_format --format --size=4096” without the --ffmt2 flag, canceled the format, rebooted and then --ffmt2, it formatted quickly and changed the Cluster Size. The hard drive worked for a year without issues.
I did the same thing to another hard drive and stashed it. Bought another 8tb drive to have a quickswap and finally decided to put that first drive in parity.
Parity started calculating and I got read errors on both 8tb hard drives. Just read errors, not write errors, only when making the parity.
Stopped everything, formatted the parity drive with the slow format, took 14 hours, did it again… old hard drive was giving reading errors, new hard drive was not. So I copied all the files over (no read errors there), formatted the data drive slowly, swapped the then-parity, now backup into the new data, put the old data into a new parity, started calculating parity again and no error so far, running for 2 hours.
In other words, doing the “hacky” quick format I performed worked as a regular array drive (never a single error on them), but doesn’t work for when using parity. Slow format was the only way to make them actually work.
tl;dr: quick format doesn’t seem worth it, at least not in the scenario where it doesn’t straight up work.
1 Like
Firstly, a big thank you to all for helping with working out to format these Oracle drives to full capacity.
I myself have acquired some of the 10TB versions, which I managet to format by running the --size=4096 parameter. One issue I have found since, is that the SMART Health status is now showing some strange values. Has anyone else encountered something similar? I have run badblocks, which has come back clear, but SMART isn’t looking good. Screenshot below:
Any help will be highly appreciated.
Apologies for the quick reply, the below screenshot is from another drive with a different SMART Health status:
These are just warnings, and are most likely warnings from the custom Oracle firmware owing from the changes made. This particular combination is not defined in the T10 SCSI standards. You can safely ignore them.
1 Like