On Mon, Apr 23, 2012 at 8:08 AM, Ross S. W. Walker
The performance bottleneck is the fact that there is a single disk queue per-target, not volume ,which causes multiple IO streams to different drives to fragment and randomize.
On Apr 23, 2012, at 1:52 AM, "Nenad Bosnjak" <email@example.com
> What I would like to know just for curiosity is why performance are shared inside target? Is it just the lack of MC/S (which if I'm correct none of OSS implementation haven't got anyway) or something else prevent saturation of target server NIC's. I use blockIO, dualcore 3GHz Xeon and 2GB RAM (cca 1GB free) so it's not hardware. On the other hand almost all commercial iSCSI targets I ran into can have only one target...
The more wthreads the better the random IO performance and the worse the sequential IO performance, the less wthreads is the opposite.
> I know of necessity to start with LUN0 but thanks for head start. In case of one LUN per target should I change for example the >>Wthreads<< value or having 64 threads is perfectly OK, system is used only for iSCSI and only other user daemon is Adaptec ASM (unfortunately java).
I have found 8 to be the perfect balance between random/sequential performance.
To get best MPIO performance with ESX make sure the MPIO driver does 1 IO per path.
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.