Is there a way to stream line this for say 72 drives 
Is there any way to just keep using it with 520 byte blocks?
Is 520 just unsupported by Linux? Would a BSD or Solaris/Illumos OS handle it properly instead?
3 Likes
Bash script?
2 Likes
thanks for the the direction wendell never used linux before time to start learning
1 Like
Hi wendell,
Thanks for the awesome guide.
I did the same as you and the drives succesfully formated with sgutils to 512 byte sector sized drives. The only issue I am facing now is that I can’t format de disks with a filesystem… In windows disk magagement I am able to initialize as a GPT drive. But creating a simplevolume will not work…
I am running a dell r710 with a h200 in IT mode and as a host OS i am running ESXI 6.7 .
I am passing that HBA through to the Win VM.
The drives I have are Seagate Constellations 3TB drives.
Do you have any idea what the cause can be ?
I have also tried to create a datastore directly under ESXI but that also does not work.
Errors from trying to do it with parted under ubuntu 18.04:
Blockquote
Jan 28 10:52:05 ubuntubak systemd-udevd[2863]: Process ‘/sbin/mdadm -If sda1 --path pci-0000:03:00.0-sas-phy3-lun-0’ failed with exit code 1.
Jan 28 10:52:05 ubuntubak systemd-udevd[2864]: Process ‘/sbin/mdadm -If sda2 --path pci-0000:03:00.0-sas-phy3-lun-0’ failed with exit code 1.
Jan 28 10:52:19 ubuntubak kernel: [ 1682.695085] sd 16:0:4:0: [sde] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 28 10:52:19 ubuntubak kernel: [ 1682.695089] sd 16:0:4:0: [sde] tag#1 Sense Key : Hardware Error [current] [descriptor]
Jan 28 10:52:19 ubuntubak kernel: [ 1682.695092] sd 16:0:4:0: [sde] tag#1 <>ASC=0x81 ASCQ=0x0
Jan 28 10:52:19 ubuntubak kernel: [ 1682.695095] sd 16:0:4:0: [sde] tag#1 CDB: Write(16) 8a 00 00 00 00 00 00 00 00 00 00 00 00 18 00 00
Jan 28 10:52:19 ubuntubak kernel: [ 1682.695097] print_req_error: critical target error, dev sde, sector 0
Jan 28 10:52:19 ubuntubak kernel: [ 1682.695651] buffer_io_error: 6 callbacks suppressed
Jan 28 10:52:19 ubuntubak kernel: [ 1682.695652] Buffer I/O error on dev sde, logical block 0, lost async page write
Jan 28 10:52:19 ubuntubak kernel: [ 1682.696177] Buffer I/O error on dev sde, logical block 1, lost async page write
Jan 28 10:52:19 ubuntubak kernel: [ 1682.696670] Buffer I/O error on dev sde, logical block 2, lost async page write
Jan 28 10:52:19 ubuntubak kernel: [ 1682.697153] sd 16:0:4:0: [sde] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 28 10:52:19 ubuntubak kernel: [ 1682.697156] sd 16:0:4:0: [sde] tag#0 Sense Key : Hardware Error [current] [descriptor]
Jan 28 10:52:19 ubuntubak kernel: [ 1682.697159] sd 16:0:4:0: [sde] tag#0 <>ASC=0x81 ASCQ=0x0
Jan 28 10:52:19 ubuntubak kernel: [ 1682.697161] sd 16:0:4:0: [sde] tag#0 CDB: Write(16) 8a 00 00 00 00 01 5d 50 a3 98 00 00 00 18 00 00
Jan 28 10:52:19 ubuntubak kernel: [ 1682.697162] print_req_error: critical target error, dev sde, sector 5860533144
Jan 28 10:52:19 ubuntubak kernel: [ 1682.697786] Buffer I/O error on dev sde, logical block 732566643, lost async page write
Jan 28 10:52:19 ubuntubak kernel: [ 1682.698365] Buffer I/O error on dev sde, logical block 732566644, lost async page write
Jan 28 10:52:19 ubuntubak kernel: [ 1682.698888] Buffer I/O error on dev sde, logical block 732566645, lost async page write
Jan 28 10:52:19 ubuntubak kernel: [ 1682.872079] sd 16:0:4:0: [sde] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 28 10:52:19 ubuntubak kernel: [ 1682.872156] sd 16:0:4:0: [sde] tag#1 Sense Key : Hardware Error [current] [descriptor]
Jan 28 10:52:19 ubuntubak kernel: [ 1682.872165] sd 16:0:4:0: [sde] tag#1 <>ASC=0x81 ASCQ=0x0
Jan 28 10:52:19 ubuntubak kernel: [ 1682.872172] sd 16:0:4:0: [sde] tag#1 CDB: Write(16) 8a 00 00 00 00 01 5d 50 a3 88 00 00 00 28 00 00
Thanks,
Mat.
I know I’m reopening an old thread but like Mat, I ran into the same issue and I did not find a solution on the L1 tech forums. Hopefully, this helps someone else. After mountains of reading, I found an argument you can set to format these drives when having those errors. --six is the argument for mode sense to set 6 byte mode sense instead of the default 10-byte mode sense. Netapp uses a 10byte mode but 4 are for checksum so you have to use the 6-byte option. I’m sure others use a similar setup. The final command will look something like this sudo sg_format -v --format --size=512 --six /dev/sdx
I’m currently using a PowerEdge R420 with a Dell HBA (03ddjt) H200e and a Netapp ds 2246 disk shelf.
5 Likes
Recently, I bought one of these SanDisk SSD drives, alongside some platter 8TB drives. They were all converted from 520 byte sectors and came pre-formatted as 512 byte, making them work perfectly on my PERC200 DELL SAS card. No issues there, but they do report as being “7.9TB drives” and the SSD reports itself as being “1.9TB”.
Reading up on the 8TB platter drives, I found out that the size disparity is because, on those drives, 512 byte (logical) sector generates a lot of parity bytes, which makes the size be smaller than 8TB. Re-formatting the drives to 4096 byte sector (logical) aligns them with the physical sectors and solves that issue, as there are less “parity bytes” to keep, providing the drive’s actual size as storage.
Would formatting these Sandisk 2TB drives as 4096 byte sectors also solve the issue of them reporting as 1.9TB? Does it even support it? I see that they also have 4096 sectors physically (both on mine and on your drive diagnostics), so I wondered if it’s the same issue with these unrelated platter drives that show the same issue (less storage than it’s supposed to be). I would try it myself, but my current SAS controller doesn’t support 4kn.
The datasheet from the device (google “sandisk-optimus-eco-sas-ssds-datasheet.pdf”, as I can’t post links) doesn’t mention 4096b support, but I don’t have much experience with SAS drives and controllers, and the device itself reports having 4096 physical blocks, so I’m curious.
This saved me alot of frustration. I could finally create a zpool on my 3TB SAS disks. Thnx alot for this guide.
1 Like
Hello everybody
i have ssd 3par sas 6Gb and sas 12Gb with 520 sector , i formatted with sg3_utils to 512 sector successfully but all ssd are very slow in windows hardisk manager when i initialised or formating .
someone have advices for me to help to have ssd more speed ?
tks and soryy for my poor english 
leave them on for many hours as after this format they may be doing a self-trim. Or make sure you controller properly supports trim.
after sending the trim command, after a long while, the drive will be very hot and return to normal.
please make sure your drives have adequate cooling.
4 Likes
#rewrite bytesize of sectors on SAS disks
#also check: How to reformat 520 byte drives to 512 bytes (usually)
single version:
sg_format -v --format --size=512 /dev/sg2
loop for multiple
for disk in $(ls /dev/da{#first…#last}); do echo “>>> ${disk} <<<” && sg_format -v --format --size=512 ${disk}
; done
replace #first with your first drive number i.e. da0 and #last with the lastnumeber i.e. da12
1 Like
So i bought some Samsung EMC SSDs with Sata but they won’t let me format them and i’ve read that Sata doesn’t allow for block size change. Is this true? Or is there any one with the same problem?
The SSDs are MZ3S92000XACP
Edit: the method tried in this post was not successful. It formats, but does not change the block size.
Just joined up to comment that I tried both the original command, and the ‘–six’ option, and tried formatting at 528 bytes (which my drive came as) then immediately reformatting to 512, but none of these worked (all reported “Illegal request sense key” or similar). For the record, this one is a Seagate Constellation ES2 (DXS2D-H3R0SS/ST33000650SS) 3TB drive.
What appears to have worked in the end was sg_format -F -F -F --size=512 /dev/blah (ie, passing the --format option three times, which the doc says means “FORMAT UNIT command only”, I assume it doesn’t do mode sense / status command first, and I guess that was what was erroring out when the block size didn’t match.)
It is currently in the process of formatting so I am taking that as a success, but I’ll come back and edit this post if it turns out to have failed (if the block size didn’t change).
5 Likes
This was the most comprehensive result I found from searching, so I figured this was the best place to put it. 
(Hello, future people tearing your hair out over uncooperative drives.)
2 Likes
fwiw I had a couple of stubborn drives but hot plugging them right before formatting seemed to get their cooperation. Since this original post, and my original 12 drives, four have died.
I might do this holy hell!
Next server upgrade might be in a few years but massive storage array of SSDs when. Then again I don’t really know of ZFS Raid Z2 or Z3 works well on SSDs yet. It might chew them up. Not sure.
See I would love to take down the caching to just mets data. I have way more RAM than I need but if I have SSDs those would be suitably fast enough to be metadata only caches for the l2 and primary cache. Keep the arc size smaller and Its memory usage lower
Though tbch if I was going this route I should really just Linus tech tips it. Grab an older threadripper or epyc. And use the insane PCIE lanes say 32 of them for 8x NVME expansion. That would be a crazy array but hey in 5 years time there light be hardware to feasibly do it for cheap!
Pretty sure the goal is to always make the CPU the bottleneck. LOL
Had an issue like this… here was my solution…
1 Like
Thank you! I was just coming back to report that my attempt using sg_format -F -F -F did NOT work, so I will try this instead now.
(For the curious - I was too hasty; it’s necessary to send the mode select command - which was failing - otherwise the format will just reformat using the current parameters.)
Also for a quicker reference - the tool linked to in the other thread is the ‘setblocksize’ repo on github:ahouston.
1 Like