On Mon, 2013-08-26 at 22:30 -0600, Scott Hallowell wrote: > Jörn, > > > > > To me this indicates a latency issue. If you can measure the average > > latency from windows or any other initiator, you could quickly > > confirm. And the likely cause is the usual: cheating. Caching all > > data in memory will turn the problem from latency-limited to > > bandwidth-limited - at the cost of the odd data corruption if you > > happen to crash or get a power failure. > > > > Given the fact the same initiator client talking to a different NAS > (from Synology) is performing considerably faster, I think that would > suggest the source of the latency is on the Linux system which I am > using for my iSCSI target. I also assume, because Samba does so well, > that the issue would be on the disk side of the iSCSI. Would you > concur? > No. As Christoph mentioned, Samba is by default putting all writes into buffer cache, so it's doing the equivalent of buffered FILEIO export with the target. When data goes into buffer cache, it's not limited by the speed of the underlying software raid, because writes are immediately acknowledged back to the initiator, and dirty data written out in the background. If you want good write performance, I would suggest using bcache with an SSD to cache writes in writeback mode, and use iscsi-target export for the local bcache block device. Also, I'd suggest avoiding Synology entirely, as they are doing a bunch of vendor specific garbage in a ancient pre-mainline version of LIO. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
