On Mon, 26 August 2013 22:30:23 -0600, Scott Hallowell wrote: > > > 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? Let me repeat: Samba and Synology are very likely cheating. Trying to compete on those terms is like riding the Tour de France without doping. You don't have a chance. And they are cheating in the usual way. They claim to have received the data once it has hit volatile memory. If the array crashes or loses power between that moment and the writeback to non-volatile memory, your data is gone. This is the oldest game in storage. Christoph has mentioned that samba is cheating by default and Nick seems to have confirmed that for Synology as well. If you want to test this hypothesis, you can do power-fail testing. Write some random data, yank the power after the array has promised you to have written the data, let it boot back up and check on the promise. A usb-controlled power strip is excellent for such tests. Jörn -- Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code. -- Christopher Thompson -- 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
