On Feb. 02, 2008, 19:18 +0200, Miguel Gonzalez Castaños <[EMAIL PROTECTED]> 
> Miguel Gonzalez Castaños escribió:
>> Hi,
>>   I've been recommended by Mike Christie to perform raw benchmarks with 
>> disktest:
>>   for reads:
>>   disktest -PT -T30  -K32 -B128k -ID /dev/sdXYZ -h1
>>   for writes:
>>   disktest -PT -T30  -K32 -B128k -ID /dev/sdXYZ -h1 -D 0:100
>>   I'm testing virtual machines using iSCSI. Virtual Server has a 
>> bottleneck with the network emulation. It works fine for the rest of the 
>> services but not for iSCSI.
>>   I've tried with VMware, and honestly, the best performance I get is 
>> using the iSCSI Windows initiator and create the virtual hard drive on 
>> the Windows partition that I create through iSCSI.
>>   However, I'm still trying to compare direct iSCSI from linux versus 
>> hard drives created on iSCSI windows partitions but using the 
>> filesystem. I've tried using:
>>   dd if=/dev/zero of=/mnt/virtualdata1/zero bs=4096 count=1572864
>>   dd if=/mnt/virtualdata1/zero of=/dev/null bs=4096
>>   and then I get very low performances (around 10-14 MB/s) or even less.
>>   While testing raw performance the difference is huge:
>>    disk on iSCSI Windows Reads: 1759.08MB/s Writes: 93.70MB/s

Read performance seems suspiciously high here, as if you're reading
from cache and not from the device.

>>    disk using open-iscsi  Reads: 35.84MB/s Writes: 57.39MB/s
>>     I've tried changing MTU, and only changing the scheduler to noop I 
>> get better reads performance.
>>     But when It comes to filesystem, apparently performances are pretty 
>> more the same. Maybe dd is not very reliable? (I've tested it and kill 
>> the process in about one minute and the numbers vary a lot)

dd is very reliable, and you should not kill it, let it finish.
It's important especially for writes where you want it to take 
close time into account.  It may take the bulk of the time to flush
the data to disk on close (i.e. dd may fill the cache quickly if
you write little enough data and then wait for it to be flushed
when the file is either fsync'ed or closed).

> I've found that changing the mount options of ext3 to noatime,nodiratime 
> the performance improves a lot, anyone knows if it is a good idea to use 
> this settings?

Keeping (persistent) track of file/dir access time causes writes
during the read-only access and that probably what causes the performance drop.

Many users do not need to keep track of file and directory access times so
these mount options are acceptable.

However, typically the file system writes are cached so they can be
optimized and amortized over larger number of operations.
Can you please try (much) bigger block sizes? 64k, 256k, 1024k maybe?


> Thanks
> Miguel

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to