On Fri, Jul 27, 2012 at 7:20 AM, Florin Iucha <florin at iucha.net> wrote: > On Thu, Jul 26, 2012 at 11:44:05PM -0500, Robert Nesius wrote: > > With iSCSI, where is the filesystem management overhead?Is the > > filesystem overhead is on the client side with the server just receiving > > low-level I/O operations that go straight to disk, whereas with CIFS the > > server is having to handle mapping the I/O from the filesystem layer > > through to hardware layer, causing it to be slower on it's responses > > (ACKS)? I've never worked with it myself... just curious. > > Yes, that's how it works. However, I am measuring the performance of > the system composed of the two machines (plus the switch) and iSCSI > shows twice the performance of CIFS. Somebody has to do the > filesystem dirty work, be it on the client or on the server. > > I could see where you have a workload that you spread across two > sub-systems and if one of them reaches capacity, that limits the > throughput of the entire system (some variation of Amdahl's law). > I think there is more post-processing on the server side and that's going to slow down server responses and that's going to push back upstream and cause writes to wait. > > But both boxes are very powerful (3.3GHz 6-core for workstation, > 2.8GHz 4-core for server) and completely idle that neither is the > bottleneck. I'm writing a 11GB file, and the server has 16GB of RAM. > If they are idle then that suggests to me they are blocking for I/O (waiting). Your drive lights are lit up pretty solidly yeah? Are you writing to a RAM DISK? > The CIFS results were so bad, I was concerned there was a problem with > the hardware. It just occurred me two days ago that I could flip things > around, use iSCSI and test the system performance in a different way. > I'm thinking of ways to test my hypothesis. I'm not sure changing the size of the TCP window on the cifs server will have an impact if the CIFS client is blocking and waiting for a response to a write. Maybe watch each of your tests with wireshark and watch latencies? -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20120727/9793b401/attachment-0001.html>