On Jun 4, 2008, at 9:33 AM, David Konerding wrote: > Hi, > > We have a bunch of Linux clients (SLES 10 SP1) which mount a NetApp > filer. > > When the NetApp gets very, very busy, for example, one user is > deleting 1Tbyte of data > while another user is doing a 30 client throughput test, it will stop > responding to some requests. > > Although we are using hard mounts, some users report that during the > hammering period, some of their > file operations produce "I/O Error" messages on their terminal. > > We checked, and the hosts are indeed using hard mounting. From our > reading, I/O Errors > should only ever make it back to the user if are using soft mounting. > > We're pretty sure the filer is not sending back an NFS_ERR response > (and we're > pretty sure that wouldn't get reported to the user as an I/O Error...) > > At this point, we suspect there must be a path in the NFS > implementation that returns I/O Error to user > space even with a hard mount. > > Any ideas? One place where this can occur is if XDR encoding or decoding fails. This is not too likely though. I would look at the RPC client's decoding logic first: call_decode() and friends. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ NFS maillist - NFS@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/nfs _______________________________________________ Please note that nfs@xxxxxxxxxxxxxxxxxxxxx is being discontinued. Please subscribe to linux-nfs@xxxxxxxxxxxxxxx instead. http://vger.kernel.org/vger-lists.html#linux-nfs -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
