The Latest Gartner® Magic Quadrant™Hyperconverged Infrastructure Software
Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)
3) In Computer manager I selected the disk and took it offline.
AKnowles wrote:The device is a SSD ( I think the page.block size is 8K), NTFS block size was 4K. When I cleaned it, as a raw disk it had no formated block size. Under ESXi it was formatted as VMFS 5 with a 1MB blocksize. I have it currently working as a NTFS disk with an imagefile.
I only reported it as an error because it is a beta abnd I thought you'd like to know it failed.
I am curious though why you state a disk bridge is not as good a choice as an imagefile though since I thought a raw disk natively formatted as VMFS might perform better since it did not have to deal with the underlying OS overhead.
AKnowles wrote:Hmm, I already posted the original log of the failed mount (second zip file). As for determining the sector size, do you have a specific command to run to determine that?
Also, I am only using thick image files. I found the LSFS method to cause too much performance loss for the initial writes to be acceptable (based on the I/O meter results. A repeat after the LSFS had grown to size was much better, but in my opinion not worth the performance difference. FWIW, I created the IO Meter VMs using eager zero thick on the LSFS backing and expected better performance the first time I ran the tests.
There were modifications in caching and that caused the problem for DiskBridge. We are fixing it. I'll give you the updated build ASAP.AKnowles wrote:For bit more clarification ...
Initially I used Starwind to export a previously formatted disk using the Physical Disk (Disk Bridging method). That method failed to present the LUN to ESXi 5.5. After I took the disk offline, I was able to successfully use Starwind to export the disk (disk bridging), but ESXi 5.5 was unable to format it. Only after I cleaned thr disk - wiping all partition information - was I able to export it using Starwind, successfully present the LUN to ESXi 5.5, and format it as VMFS 5. The LUN did not fail until after I started to copy a VM to it. It failed at 11~13 percent with the general I/O error.
If you would like me to try a different method, please let me know.
AKnowles wrote:Anton,
The numbers above relate to an issue I noticed with Thick vs. Thin provisioning not specifically SSD related. The first set I posted (earlier in the thread) are on the SSD. I did not initialize the SSD between uses. Just deleted the LUN and files then recreated them.
The numbers directly above are on the Arcea 1261 RAID 5 disk (10 Seagate 7200 RPM 2.5" SATA). I have partitioned the disk in to two partitions so the first part of the disk is used for iSCSI LUNs and the rest for shared files. I will try and recreate the test on a single host to remove the possibility of vMotions, other VMs access causing contention, etc. a bit later this week since the number are not quite what I expected.