Kamal Jain wrote:
Hi Wendy,
IOZONE v3.283 was used to generate the results I posted.
An example invocation line [for the IOPS result]:
./iozone -O -l 1 -u 8 -T -b /root/iozone_IOPS_1_TO_8_THREAD_1_DISK_ISCSI_DIRECT.xls -F /mnt/iscsi_direct1/iozone/iozone1.tmp ...
It's for 1 to 8 threads, and I provided 8 file names through I'm only showing one in the line above. The file destinations were on the same disk for a single disk test, and on alternating disks for a 2-disk test. I believe IOZONE uses a simple random string, repeated in certain default record sizes, when performing its various operations.
Intuitively (by reading your iozone command), this is a locking issue.
There are lots to say on your setup, mostly because all data and lock
traffic are funneling thru the same network. Remember locking is mostly
to do with *latency*, not bandwidth. So even your network is not
saturated, the performance can go down. It is different from the rsync
issue (as described by Jos Vos) so the glock trimming patch is not
helpful in this case.
However, I won't know for sure until we get the data analyzed. Thanks
for the input.
-- Wendy
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
