Performance impact of 512byte vs 4K sector sizes

When you are designing your storage subsystem. On modern hardware, you will often be asked to choose between formatting using 512 byte or 4K (4096 byte) sectors. This article discusses whether there is any statistically observable performance difference between the two in a 512 vs. 4K performance test.

NB: Do not get confused between the EXT4 INODE size and the LUN sector size. The INODE size places a mathematical cap on the number of files that a file system can store, and by consequence how large the volume can be. The sector size relates to how the file system interacts with the physical underlying hardware.

QNAP Sector Size selection
Sector Size selection on QNAP QTS 4.3.6

Method

  • A QNAP TS-1277XU-RP with 8x WD Red Pro 7200 RPM WD6003FFBX-68MU3N0 drives running firmware 83.00A83 were installed with 8 drives in bays 5 – 12
  • Storage shelf firmware was updated to QTS version 4.3.6.0923, providing the latest platform enhancements
  • A Storage Pool comprising all 8 disks in RAID 6 was configured, ensuring redundancy
  • A 4GB volume was added allowing QNAP app installation so that the systme could finish installing
  • The disk shelf was rebooted after it had completed its own setup tasks
  • RAID sync was allowed to fully complete over the next 12 hours
  • Two identical 4096 GB iSCSI targets were created with identical configurations apart from one having 512 byte and the other 4k sector sizes
  • SSD caching was disabled on the storage shelf
  • 2x10Gbps Ethernet, dedicated iSCSI connections were made available through two Dell PowerConnect SAN switches. Each NIC on its own VLAN. 9k jumbo frames were enabled accross the fabric
  • A Windows Server 2016 hypervisor was connected to the iSCSI target and mounted the storage volume. iSCSI MPIO was enabled in Round Robin mode. Representing a typical hypervisor configuration
  • The two storage LUNs were formatted with 64K NTFS partitions (recommended for dedicated VHDX volumes)
  • A Windows 10 VM was migrated onto each of the targets and the test performed using Anvil’s Storage Utilities 1.1.0.20140101. The VM had no live network connections. The Super Fetch and Windows Update services were disabled, preventing undesirable disk I/O. The VM was not rebooted between tests, had no other running tasks and had been idling for 6 hours prior to the test
  • No other tasks, load or data were present on the storage array

 

512 vs. 4K Performace Results

The results of the two tests are shown below.

Anvil Storage Utilities Screenshot with 512bytes results
Anvil Storage Utilities Screenshot with 512bytes results

"Anvil

IOPS
512 byte 4K 4K Diff 4K Diff % +/-
Read Seq 4MB 417.45 403.3 -14.15 -3.51
4K 3001.56 3164.56 163 5.15
4K QD4 6021.45 6006.7 -14.75 -0.25
4K QD16 24228.16 24062.61 -165.55 -0.69
32K 2742.39 2807.47 65.08 2.32
128K 2628.86 2620.8 -8.06 -0.31
Write Seq 4MB 233.2 230.79 -2.41 -1.04
4K 2090.79 2165.45 74.66 3.45
4K QD4 5976.18 5983.65 7.47 0.12
4K QD16 8254.84 7874.67 -380.17 -4.83

 

Analysis and Recommendations

The results show that there is little difference between the two. Repeating the tests multiple times showed that the figures for both the 512 byte and 4K LUNs are within the margin of error of each other. A bias towards 512 byte was consistently present, but was not statistically significant.

The drives in the test disk array are 512e drives. 512e is an industry transition technology between pure 512 byte and pure 4K drives. 512e drives use physical 4K sectors on the platter, but that the firmware uses 512 byte logic. A firmware emulation layer converts between the two. This creates a performance penalty during write operations due to the computation and delay of the re-mapping operation. Neither sector size will prevent this from occurring.

My recommendations are

  • If all of your drives are legacy 512 byte drives, only use 512
  • Should you intend to mount the LUN with an operating system that does not support 4K sectors. Only use 512
  • In situations where you have 512e drives, you can use either. Unless you intend to clone the LUN onto 4K drives in the future, stick with 512 for maximum compatibility
  • Never create an array that mixes 512 and 4K disks. Ensure that you create storage pools and volumes accordingly
  • Where all of your drives are 4K, only use 4K

 

QNAP TVS-1271U Top Row of Drives (drives 9-12) do not start on boot/reboot of the NAS appliance

System Requirements:

  • QNAP TVS-1271U
  • QTS 4.3

The Problem:

A brand new, out of the box 12 drive 2u NAS appliance, with the “firmware” up to date gets thrown into production. During its first maintenance cycle, the firmware is updated again and it is rebooted.

On completion of the reboot, the array is offline. Visual inspection of the appliance reveals that the top row of drives in the array, drives 9, 10, 11 and 12 are offline. They just are not powered. Drives 1-8 are online and all green.

Rebooting the array shows the diagnostic LED’s on all 12 drives flash red, but the 4 drives in question then go into a powered down state and the boot completes with an inconsistent volume layout.

  1. Hot swapping the drives did not make a difference
  2. Rebooting the array did not make a difference.
  3. Testing all of the top rows worth of drives externally showed no errors in any drives
  4. Performing a couple of hard power downs and cold booting did solve the problem and allowed the array to start normally.

The same thing happened during the next test and diagnostics window.

The Fix

Disgruntled customer note: I want to add at this point that trying to phone QNAP UK is an exercise in futility. I sat in their queue system for more than half an hour listening to the same loop of music without getting anywhere. By the time that I gave up, I’d managed to get the thing to start through cold boot cycles and done quick SMART tests on all of the drives. When it came to this occurring the second time, I used the online chat feature with their people in Taiwan, who were more responsive and most helpful, but would not entertain speaking on the phone come what may.

My bigger issue is that QNAP support seems to have little sympathy for the needs of a production IT department, where as you would have thought that QNAP would be the kings of working to such constraints.

 

Once I had got to second line, the fix in itself was quite simple in the end, but its implementation leaves something to be desired. The system needed a BIOS update.

You might assume that when you are updating your “firmware“, this sort of things is being accommodated for in those updates. Apparently not! It seems as this new device may have been sitting in a warehouse for some time so was out of date, but it was immediately firmware serviced as soon as it was first booted. You would have expected that this sort of well know about, intermittent issue was being dealt with through the update delivery mechanism.

As soon as the BIOS of the TVS-1271U was updated to version QW10IR12 and rebooted, the problem was fixed. Why QNAP have not put information on this on their website knowledge base I do not know. This would seem more than sensible. QNAP does itself more reputational damage by trying to hide the issue and hope that only a few people see it. The reality is that they are likely causing stress and grief to end users and unnecessary RMA’s to their suppliers.

After checking power rails, our initial response was that it was a dead backplane and we were assuming it would have to be an RMA. Fortunately, it wasn’t and fortunately I went to QNAP before I went back to the supplier, but you do not always, especially with companies increasingly insisting that you deal with suppliers for RMA processes. A little public disclosure about this known issue would have just saved a lot of headaches (and disclosure makes you look good QNAP!).

The execution of the BIOS update itself was unfortunately quite cumbersome, requiring the support tech to back-up and then re-programme all of the NIC MAC addresses built into the motherboard. Something that could have easily have been sorted in a shall script and then transparently bundled into the firmware delivery, saving QNAP Taiwan more than an hours’ worth of time on this and some 8 emails.

It did however fix the problem and the Taiwan support team were pretty accomodating about doing it at 7am UK time.

Here for the benefit of the rest of the world, is the process that the tech went through to flash the BIOS. I have substituted real MAC addresses with fake ones below.

Note: I strongly recommend that you do not try this yourself and that you contact QNAP via their web chat support if you have a need to perform this procedure. If you try it, it is entirely at your own risk.

login as: admin
admin@192.168.1.1's password:
[~] # md_checker Welcome to MD superblock checker (v1.4) - have a nice day~ Scanning system... HAL firmware detected!
Scanning Enclosure 0...
RAID metadata found!
UUID: 3e5d7c85:95d82d3e:42647860:c0aaec32
Level: raid6
Devices: 12
Name: md2
Chunk Size: 512K
md Version: 1.0
Creation Time: Apr 19 11:57:42 2017
Status: ONLINE (md2) [UUUUUUUUUUUU]
===============================================================================
Disk | Device | # | Status | Last Update Time | Events | Array State
===============================================================================
1 /dev/sdc3 0 Active Jun 16 07:15:08 2017 156 AAAAAAAAAAAA
2 /dev/sdd3 1 Active Jun 16 07:15:08 2017 156 AAAAAAAAAAAA
3 /dev/sde3 2 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
4 /dev/sdf3 3 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
5 /dev/sdk3 4 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
6 /dev/sdl3 5 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
7 /dev/sdm3 6 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
8 /dev/sdn3 7 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
9 /dev/sdg3 8 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
10 /dev/sdh3 9 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
11 /dev/sdi3 10 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
12 /dev/sdj3 11 Active Jun 16 07:15:08 2017 155 AAAAAAAAAAAA
=============================================================================== [~] # cd /share/CACHEDEV2_DATA/Public/
[/share/CACHEDEV2_DATA/Public] # ls
@Recycle/ messages
[/share/CACHEDEV2_DATA/Public] # wget http://download.qnap.com/Storage/tsd/bios/TVS-1271U_QW10IR12.zip
--2017-06-16 07:16:51-- http://download.qnap.com/Storage/tsd/bios/TVS-1271U_QW10IR12.zip
Resolving download.qnap.com (download.qnap.com)... 2.17.149.135, 2a02:26f0:ec:38c::1b52, 2a02:26f0:ec:398::1b52
Connecting to download.qnap.com (download.qnap.com)|2.17.149.135|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5931607 (5.7M) [application/zip]
Saving to: ‘TVS-1271U_QW10IR12.zip’ TVS-1271U_QW10IR12.zip 100%[=====================================================================>] 5.66M 5.50MB/s in 1.0s 2017-06-16 07:16:52 (5.50 MB/s) - ‘TVS-1271U_QW10IR12.zip’ saved [5931607/5931607] [/share/CACHEDEV2_DATA/Public] # chmod +x TVS-1271U_QW10IR12.zip
[/share/CACHEDEV2_DATA/Public] # unzip TVS-1271U_QW10IR12.zip
Archive: TVS-1271U_QW10IR12.zip
creating: BIOS_QW10IR12/
inflating: BIOS_QW10IR12/flashrom
inflating: BIOS_QW10IR12/QW10IR12.bin
[/share/CACHEDEV2_DATA/Public] # ls
@Recycle/ BIOS_QW10IR12/ TVS-1271U_QW10IR12.zip* messages
[/share/CACHEDEV2_DATA/Public] # dmidecode -t bios | grep version
[/share/CACHEDEV2_DATA/Public] # cd
[~] # cd /
[/] # dmidecode -t bios | grep version
[/] # cd -
/root
[~] # cd /share/CACHEDEV2_DATA/Public/
[/share/CACHEDEV2_DATA/Public] # head /etc/config/uLinux.conf
[System]
Model = TS-X71U
Internal Model = TS-X71
Server comment =
Version = 4.3.3
Build Number = 20170606
Number = 0224
Time Zone = Europe/London
Enable Daylight Saving Time = TRUE
Workgroup = QNAP
[/share/CACHEDEV2_DATA/Public] # cat /etc/model.conf | grep INTERNAL_NET_PORT_NUM
INTERNAL_NET_PORT_NUM = 4
[/share/CACHEDEV2_DATA/Public] # hal_app --se_sys_get_mac obj_index=0
35:35:35:35:36:31
[/share/CACHEDEV2_DATA/Public] # hal_app --se_sys_get_mac obj_index=1
35:35:35:35:36:32
[/share/CACHEDEV2_DATA/Public] # hal_app --se_sys_get_mac obj_index=2
35:35:35:35:36:33
[/share/CACHEDEV2_DATA/Public] # hal_app --se_sys_get_mac obj_index=3
35:35:35:35:36:34
[/share/CACHEDEV2_DATA/Public] # cd
[~] # cd /share/Public
[/share/Public] # ls
@Recycle/ BIOS_QW10IR12/ TVS-1271U_QW10IR12.zip* messages
[/share/Public] # cd BIOS_QW10IR12/
[/share/Public/BIOS_QW10IR12] # ls
QW10IR12.bin flashrom
[/share/Public/BIOS_QW10IR12] # ls
QW10IR12.bin flashrom
[/share/Public/BIOS_QW10IR12] # chmod +x *
[/share/Public/BIOS_QW10IR12] # ls
QW10IR12.bin* flashrom*
[/share/Public/BIOS_QW10IR12] # ./flashrom -c MX25L128050 --programmer internal -w QW10IR12.bin
flashrom v0.9.8-unknown on Linux 4.2.8 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org Error: Unknown chip 'MX25L128050' specified.
Run flashrom -L to view the hardware supported in this flashrom version.
[/share/Public/BIOS_QW10IR12] # ./flashrom -c MX25L12805D --programmer internal -w QW10IR12.bin
flashrom v0.9.8-unknown on Linux 4.2.8 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK.
Found chipset "Intel C226".
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with it,
then please email a report to flashrom@flashrom.org including a verbose (-V) log.
Thank you!
Enabling flash write... Warning: SPI Configuration Lockdown activated.
OK.
Found Macronix flash chip "MX25L12805D" (16384 kB, SPI) mapped at physical address 0xff000000.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
[/share/Public/BIOS_QW10IR12] # hal_app --se_sys_set_mac obj_index=0,value=35:35:35:35:36:81
eth port = 0, Set MAC address = 35:35:35:35:36:31,ret = 0
[/share/Public/BIOS_QW10IR12] # hal_app --se_sys_set_mac obj_index=1,value=35:35:35:35:36:82
eth port = 1, Set MAC address = 35:35:35:35:36:32,ret = 0
[/share/Public/BIOS_QW10IR12] # hal_app --se_sys_set_mac obj_index=2,value=35:35:35:35:36:83
eth port = 2, Set MAC address = 35:35:35:35:36:33,ret = 0
[/share/Public/BIOS_QW10IR12] # hal_app --se_sys_set_mac obj_index=3,value=35:35:35:35:36:84
eth port = 3, Set MAC address = 35:35:35:35:36:34,ret = 0
[/share/Public/BIOS_QW10IR12] # reboot