Good day,
Sorry for my English, it is not my native language, and recenly I have less than it should be practice in analytical writing.
I have an ESXi 6.0.0 Update 2 installed on a bare metal HP Proliant server. It operatesgood enough with 2 external HDD enclosures, connected via 2 P411 RAID controllers. On top of that, some of the server's internal 2.5" slots are occupied with SSD (just a handful of them) served by HP onboard integrated P410 RAID controller (yes I know it is bad). All the HDDs and SSDs are split into a few datastores depending on their size and RPM, and all datastores are configured as RAID10.
Naturally there are several VM's, a lot of production data incoming daily and suddenly there is a backup solution, utilizing a dedicated VM with proper software installed, and also a dedicated datastore running on cheap 8 SATA 5400 RPM drives 3TB each, thus totaling usable 12TB of first layer onsite backup.
There is/there was a second layer of onsite backup, namely backup copy of the most critical VM's done to a 4TB ST4000NM0055 located in externally powered enclosure, connected to the backup VM via PCI passthrough PCI-USB3.1 card.
Recently the PCI-USB3.1 card failed (it was not VMWare approved but worked for about a year), and I decided to move backup copy to be connected via a more stable and failsafe path. It was done by utilizing existing unoccupied SATA port, located directly on mainboard of this HP Proliant server. The SATA port is powered, it is documented as SSD SATA, seems working via another controller, not related to abovementioned P410 and P411s.
So I sourced the proper cable and connected Seagate ST8000NM0055 to the SATA port. Immediately after connecting new drive to the backup VM via thin provisioned datastore of 7TB, I've noticed that file move performance leaves much to be desired: backup move from old USB3.0 drive started at 70-80MBps (Megabytes per second) but within 10 to 15 minutes dropped to 10MBps and stopped at that level for hours. The end for the 3TB file move operation was expected to be in 80 to 90 hours from start.
I assumed that large scale file move and underlying disk space allocation for thin provisioned VMDK is basically 2 heavy operations for the same data volume, so probably that was the reason of such unexpectedly low data transfer rate. To speed up the process I decided to inflate thin-provisioned VMDK from at that moment 300GB to targeted 7TB. So I shut down the backup VM, and right clicked inflate in VMWare vCenter operations web interface.
This happened 6 days ago and the drive is still inflating... The server is not under any heavy CPU or disk load, it's utilization is between 15 and 25% of all kind of capacity. So I think this time is beyond normal, however I have no other choice but wait, as if cancel I will lose already transferred 300GB of uncritical but sentimental data.
While checking how are the things going daily I noticed not only the write IOPS are quite low, but after 3-4 days running they suddenly increased almost twice. The only operation undergoing with that media is disk Inflate.
Write IOPS suddenly increased twice
Overall write performance is awful
Few tweaks were found and tried, like switch datastore hardware accelleration on and off in ESXi host settings, namely the following parameters - DataMover.HardwareAcceleratedInit from 1 to 0 - DataMover.HardwareAcceleratedMove from 1 to 0 - VMFS3.HardwareAcceleratedLocking from 1 to 0 they gave no impact either to SATA or to SAS datastores.
What I'm missing to have good performance for this drive? From home PC experience I expect it to have at least 100MBps operations easily, so full inflate should take 20 hours instead of up to 180 hours we're targeting currently.
TL;DR: ESXI 6.0, seems I'm stuck at 10MBps write performance for directly connected SATA HDD. Sometimes it jumps to a whooping 20MBps. Please send help to explain
