HGST HE8, 512byte vs 4k sector models?

Zarathustra[H]

Extremely [H]
Joined
Oct 29, 2000
Messages
38,819
Hey all,

So I am shopping for 8TB drives to use to upgrade my server.

Previous gen HGST He8 8TB drives are priced very competitively right now, and I ma considering going with them, but one thing I have noticed is that they are all 512byte sector models.

Most hard drives have moved to 4K sectors at this point.

Are there any downsides to buying these 512byte sector models in 2017?

Appreciate any thoughts.
 
I would get the 4KB sector models personally, having the older 512 byte just means slightly lower performance that would really only be noticeable in benchmarks but who would be using these for massive performance anyway - that's what SSDs are for. ;)

For just raw storage - and it's got to be video content because nothing else sucks up space like video files of all kinds especially with 4K content moving in nowadays - performance isn't really a serious chore for such modern storage hardware. I mean it can be useful to have some decent performance if you're doing video editing sure but if this is for some home server purposes as a video "farm" type device any modern physical hard drive will be adequate for providing content to a few sources/streams simultaneously.
 
All retail drives are 512e (4K sectors with 512 byte emulation). 4K native, if you can find it, will probably cost more, and performance is the same, so...
 
Last edited:
All retail drives are 512e (4K sectors with 512 byte emulation). 4K native, if you can find it, will probably cost more, and performance is the same, so...

Ah,

OK that explains it. I was looking through the specs, and the SATA models came in 512e and 4k variants. SAS models come in 4k and 512e as well as a mnumber of weird ass sector sizes I have no idea what they are for. (I didn't realize until right now that the e stood for emulation, but that makes sense.) I did not know that all retail models were 512e models. That would be why those are the only ones I can find.

I'm a bit surprised that this is still the case though. These drives were launched in late 2014, and I thought native 4k (without emulation) was supposed to be the standard in all new drives since 2011.

So, if these are 4k drives with 512 byte emulation - as you say - this makes absolutely no difference at all, and you would want to run them as 4k drives anyway, because 512byte emulation tends to slow things down.

My ZFS vdevs are all in "ashift=12" already, so this should be a good fit.

Thanks for the good info.
 
Actually, you should stick with 512e unless you know otherwise. 4Kn can't be used until you have confirmed that your entire hardware and software stack is ready for it. From the disk controller, BIOS/UEFI, partition tables, external docks, and on up. A lot of components/software can not handle any other size than 512.

That is why 512e is in retail, and 4Kn (native) is harder to obtain.
 
4Kn can't be used until you have confirmed that your entire hardware and software stack is ready for it.

Hmm. I have a couple of 4Kn drives (toshiba enterprise SATA 4TB models I purchased here from a seller) installed on a core2quad system. And I have no issues at all. Not sure if I am using the Intel ports or ones from a USB3 PCIe card with 2 SATA3 ports.


With that said I don't think they worked with a USB2 dock. I have since replaced it with a USB3 one. Not sure if I tried the 4Kn drives in that.

Edit: I guess that is an issue...
 
Last edited:
Actually, you should stick with 512e unless you know otherwise. 4Kn can't be used until you have confirmed that your entire hardware and software stack is ready for it. From the disk controller, BIOS/UEFI, partition tables, external docks, and on up. A lot of components/software can not handle any other size than 512.

That is why 512e is in retail, and 4Kn (native) is harder to obtain.

Hmm.

I could have sworn that every recent consumer drive I had bought was native 4k advanced format without emulation, because that was supposed to be the standard starting in 2011, but I guess I was wrong. Here is the smart output from one of my my 4TB WD Reds (WD40EFRX)

Code:
=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Red
Device Model:     WDC WD40EFRX-68WT0N0
Serial Number:  
LU WWN Device Id:
Firmware Version: 80.00A80
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Oct 11 12:30:46 2017 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

The part that I didnt know was that on the HGST drives 512e meant emulated, or logical 512byte and that the underlying sectors were natively 4k. That's exactly like my current WD Reds, so I expect this to be a drop in replacement success. Replace the drives one by one and resilver, and after the last disk is resilvered, the volume should grow.
 
Here is a 512e drive:

Code:
jmd0 ~ # hdparm -I /dev/sdf | grep -e "Sector size" -e "Model"
        Model Number:       ST4000DM000-1F2168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes

And a 4Kn drive:
Code:
jmd0 ~ # hdparm -I /dev/sda | grep -e "Sector size" -e "Model"
        Model Number:       TOSHIBA MG04ACA500A
        Logical  Sector size:                  4096 bytes
        Physical Sector size:                  4096 bytes
 
AF drives have no special requirements to be used, no special controller hardware required, no special drivers, nothing - all the Advanced Format features and functionality are managed on the drives themselves so I don't know where all this funky discussion is going and where these ideas are coming from that you require some special hardware or drivers to put such drives to use. They offer slightly improved performance from that fact that it's reading data in full 4096 byte chunks instead of the 512 byte chunks traditionally done with previous drive technology.

Think of it this way by example of a crappy analogy for the most part but it works on some levels:

This sentence you're reading has exactly eight words.

With a 512 byte layout you'd read that sentence one word at a time - with the 4096 byte layout you'd read the entire sentence at a glance as one chunk of data (speed readers read this way, in chunks, not words) hence the 4096 byte layout is more efficient by an actually measurable amount (it's not 8x faster, however, because the drive heads are still moving across the platters at the same speed regardless of it being 512 byte sectors or 4096 byte sectors). It's just a matter of how the data is being processed more than anything else and more efficient.

If AF drives required special hardware or drivers to function as designed the "advanced format' would never have been able to survive hence they just work from the git-go.
 
Last edited by a moderator:
... so I don't know where all this funky discussion is going and where these ideas are coming from that you require some special hardware or drivers to put such drives to use.
Advanced Format is 512e. Advanced Format is not 4Kn.(native)

And it is actually not true that Advanced Format has no special requirements. Software that depends on the 512-byte sector behavior of drives (e.g. database, filesystem) not destroying adjacent sectors in a crash do not work(correctly) on Advanced Format. An advanced format drive can destroy 4096-bytes if the power fails in the middle of a 512-byte write from the software. This is one reason why a lot of enterprise drives have continued to be 512n, and not Advanced Format.
The other big reason is that Advanced Format drives have a performance penalty when writes are not 4096 bytes or an even multiple of that and aligned on a 4096 byte boundary.
 

dr evil.jpg
 
The other big reason is that Advanced Format drives have a performance penalty when writes are not 4096 bytes or an even multiple of that and aligned on a 4096 byte boundary.

I was concerned about something like this going on, but it seems like ZFS is aware and configures 512e drives with ashift=12, such that it aligns and reads 8 of the chunks at a time like 4k sectors.

Old pools created under older versions of ZFS may have been created with ashift=9 though, resulting in horrid performance on advanced format drives with emulated 512byte sectors

The only way to change the ashift of a vdev is to destroy it and create it again.

For the sake of posterity, if anyone needs to check their pool, the following command will do the trick:

zdb -C | grep ashift

ashift=9 means a sector size of 512, which will be terrible for newer drives, even if they have 512 byte emulation.

ashift=12 means a 4k Sector size which will work well on both advanced format, native 4k and native 512 byte drives.

Modern versions of ZFS create pools with ashift=12 as default.
 
Last edited:
The motivation to switch to 4K sectors ("advanced format") was to increase disk capacity, by decreasing error correction overhead, which had been growing. This does increase the sequential transfer rate, but really, who cares. It was about getting more capacity at no cost.

4K is a convenient size because x86 and other CPUs use 4K pages, and commonly used filesystems use 4K allocation units. So most things were already 4K ready without modification, provided that partitions were 4K aligned.
 
Back
Top