HGST HC520 512e to 4Kn?

jolness

New Member
May 25, 2020
8
0
1
I figure now is going to be the easiest time to do this but am unsure if there are any advantages in my application (FreeNAS on ESXi with a 9300-8i passed through for the drives). Tried going through a couple of whitepapers I found and they were quite dense for my knowledge level but I know there are plenty of folks here who could help me educate myself on benefits and how to do so if they are there for me.
If there is a benefit, how do I accomplish this, is it something that can be done with a Linux utility, or do I need something like Niagra to do so?

Thank you in advance!
 

i386

Well-Known Member
Mar 18, 2016
2,323
641
113
31
Germany
The advantage of native block sizes versus emulated is that for native blocksize no mapping is required (lower latency, relevant for ssds). (See Advanced Format - Wikipedia for more information about efficiency and how the mapping works).
The sg3 utils support formatting with a different blocksize. I have changed the blocksize from 512 to 4096 bytes on some hgst ssds, but not on hdds. I think this could brick the hdds becuase some hdds store parts of the firmware on directly on the platters. (If I rember correctly @Terry Kennedy mentioned it in some threads about hdds and firmware).
 

jolness

New Member
May 25, 2020
8
0
1
The advantage of native block sizes versus emulated is that for native blocksize no mapping is required (lower latency, relevant for ssds). (See Advanced Format - Wikipedia for more information about efficiency and how the mapping works).
The sg3 utils support formatting with a different blocksize. I have changed the blocksize from 512 to 4096 bytes on some hgst ssds, but not on hdds. I think this could brick the hdds becuase some hdds store parts of the firmware on directly on the platters. (If I rember correctly @Terry Kennedy mentioned it in some threads about hdds and firmware).
Hopefully someone chimes in, If that's true then obviously I'm not going to bother but figure now before I put them into production is the best time
 

Skud

Active Member
Jan 3, 2012
115
54
28
I used HUGO for my disks. Worked very well and took maybe 60 seconds to do 8 disks.


Run "hugo show" to see the disks and get the information you need. HUGO will let you do multiple disks at once with the same model number.

Then, "hugo f -m <model number from above> --fastformat -n max -b 4096". This will:

- Format *ALL* disks that have the specified model number.
- Format them to 4K
- Use the "fastformat" to just change the sector size without formatting the entire disk.
- The -n max option tells the disk to apply the change to the entire disk.

Note: Note that this won't allow you to keep any existing data. Anything written to the disk prior to the format will remain on the disk, but it would have been written with the 512e sector size. So, if you try to read the data back then it will be corrupt. Anything NEW will write-out at 4K. It would be best to just do a quick format after you do this to wipe-out any filesystems that were there.

Thanks!!
Riley
 
Last edited:
  • Like
Reactions: metag

jolness

New Member
May 25, 2020
8
0
1
I used HUGO for my disks. Worked very well and took maybe 60 seconds to do 8 disks.


Run "hugo show" to see the disks and get the information you need. HUGO will let you do multiple disks at once with the same model number.

Then, "hugo f -m <model number from above> --fastformat -n max -b 4096". This will:

- Format *ALL* disks that have the specified model number.
- Format them to 4K
- Use the "fastformat" to just change the sector size without formatting the entire disk.
- The -n max option tells the disk to format the entire disk.

Note: Note that this won't allow you to keep any existing data. Anything written to the disk prior to the format will remain on the disk, but it would have been written with the 512e sector size. So, if you try to read the data back then it will be corrupt. Anything NEW will write-out at 4K. It would be best to just do a quick format after you do this to wipe-out any filesystems that were there.

Thanks!!
Riley
Awesome!!! Thank you so much. I will be doing this when I get back on Friday from out of town. What disks did you do this on? The gentleman above mentioning the firmware possibly being stored on the platters made me a little nervous haha
 

Skud

Active Member
Jan 3, 2012
115
54
28
Awesome!!! Thank you so much. I will be doing this when I get back on Friday from out of town. What disks did you do this on? The gentleman above mentioning the firmware possibly being stored on the platters made me a little nervous haha
I did mine on the HSGT/WD DC H310 (hus726t4tal5204).
 

Terry Kennedy

Well-Known Member
Jun 25, 2015
1,072
513
113
New York City
www.glaver.org
I think this could brick the hdds becuase some hdds store parts of the firmware on directly on the platters. (If I rember correctly @Terry Kennedy mentioned it in some threads about hdds and firmware).
Drive firmware is in a protected area not affected by any user format operations. Even if it was wiped, there is enough of the firmware in flash to support downloading and rewriting the on-disk portion, but you generally need OEM-level tools for that.
 

Stephan

Active Member
Apr 21, 2017
183
79
28
Germany
What advantages on HDDs does this 512e to 4k operation have? Any at all when filesystem was clever enough to detect true 4k block size during initial creation?
 

Terry Kennedy

Well-Known Member
Jun 25, 2015
1,072
513
113
New York City
www.glaver.org
What advantages on HDDs does this 512e to 4k operation have? Any at all when filesystem was clever enough to detect true 4k block size during initial creation?
If a drive reports a 512 byte (even if emulated) sector size, many operating systems will assume that 512-byte writes are possible, even if most are for larger numbers of sectors. Not all 512e drives report that they are actually 4K inside, so there's no way for an OS to know. Updating 512 bytes of a 4K sector is a read/modify/write operation inside the drive, while a 4K write to a 4Kn drive is just a write. There are horror stories dating from the early days of 512e where the OS did not align things on a native 4K boundary, leading to horrible performance. Most (but not all, particularly on drives that lie about their actual physical sector size) have been fixed.

The only reasons to use 512e these days are: 1) controllers / operating systems that don't support 4Kn, or 2) systems without UEFI that need to boot from this media. I work around the 2nd by using a separate small SSD for boot media, while the 128TB ZFS pool is on 4Kn drives.
 
  • Like
Reactions: jolness