It is not untrue to compare apples and pears. It just depends on what you want. If you simply say "apples are better than pears", then you are mistaken, but if you say "apples suit my needs better than pears", then there is no problem, but not all can say the same statement.
What I am not sure of:
- Do I need the excellent random read and write of RAID10?
- Do I need the extra space or faster sequential speed from raidz1?
What I was testing was:
Is raidz1 slower than raid10 like everyone says, or does it match my hyphothesis: sequentially it is always faster than raid10; equal to raid0 in read, 80% (1/(disks-1) slower) compared to raid0 in write. And in "random" operations, I expect it to be slower, but I'm not sure how to test... My plan of testing random access is to "make buildworld". I don't like benchmark tools; they seem to just test block level access to a big randomly generated file, not a full file system (creating files, reading directories, etc.) which is more real world.
Others make stupid but intelligent sounding conclusions. So it is very difficult to figure out the whole truth just from reading.
And I am slowly getting fed up with ESXi.
<ESXi rant>
Today, the ESXi server was happily running while it said some vms are down and others are up. Pinging the "down" vms and using their web servers, etc. worked. So ESXi is reporting that they are "down" when really they are up. How is that even possible? One server that was "up" was responding VERY slowly, and others are reporting load >4 when idle. So I rebooted ESXi. Why should I need to reboot just to fix this? I feel like I'm running Windows... And commands like "top" and "vmstat" or even looking in /proc/... to find cpu stats isn't possible in the ESXi command line. (I'm guessing there is a way, but it is a mystery to me). Things like that make me want a real OS, not this incomplete VMware ESXi Busybox, with a semi-well documented GUI and completely obscure proprietary command line. I wanted to know the CPU usage of the vmware-vmx processes (or the ESXi equivalent), because it is a common problem for them to all hog 100% CPU and make the system crawl in other VMware products.
And a week ago, I wanted to create my first non-NFS virtual machine, and to my surprise, there was no local datasource. The path was "dead" it said. But the OS disk worked fine, so clearly the hardware was working. The bios RAID setup said things were optimal A reboot fixed it, so I can only assume the hardware is fine, but how can I trust it in the future?
So my new plan is: Run my NAS and replication/backup server with lots of disk space. Run the VMs on separate FreeBSD + ZFS + VirtualBox machines, with the virtual disk files stored locally. Send replication snapshots to the backup server, and put large volume low latency demanding stuff (which is most of what we do here) on the NAS directly. (Luckily, I am in charge of this, so I can decide whether or not to throw away ESXi; Do you have the same control?). Another option would be to netboot the ESXi, or to run it in a VirtualBox. Both of those sound like bad hacks, and since I'm fed up with ESXi, I am leaning towards a VirtualBox solution.
So my "raid10 apples vs raidz1 pears" comparison is just to decide... do I want the significantly higher space and sequential performance from raidz (raidz1 in the case of this 6 disk machine, and maybe also the 4 disk machine that currently runs ESXi, and raidz2 for larger ones), or do I want the performance characteristics of the raid10 (~50% better random [did not test myself], ~33% slower sequential write (63MB/s vs 92MB/s) and equal read (204MB/s vs 193MB/s) [my own testing on the old PowerEdge 2850]).
So far, I think I will choose raidz1 for the faster sequential writes. I think for my needs, faster transfers over the network are more important than random performance (like for a database, or compiling things). (Maybe I will compare random speeds by running make buildworld)
We are getting further off the topic of ZILs... but I think what you are interested in is virtual machine performance... so I guess we are slightly on topic. And let me know if you prefer less long-winded replies in the future.