> Knowing nothing about your situation, I'd assume the clients are > doing that because they actually want that 1MB of data. Possibly. But we have no control over that (the application read size, I mean). > Would you prefer they each send 1024 1k READs? I don't understand > why it's the read size you're focused on here. No. But 32x 32k reads is reasonable (because it gives other RPCs a look-in). I'm focused on reads because it makes up the majority of our NFS traffic. I'm concerned because as it stands (out of the box) if the majority of our n knfsd threads are waiting for a 1MB read to return then no other RPC request will be serviced and will just contribute to the backlog. This backlog itself will probably also contain a hefty no. of 1MB read requests too. In short, a lot of other RPC calls that are not reads will just be blocking and this will appear to an end user as poor performance. We deal with a great number of fairly large files - 10s of GBs in size. We just don't want others to suffer because of large request sizes coming in (writes end up being of the same size too but there are less of them). Our use cases are varied but they all have to share the same resource (the array of NFS servers). We've only really seen this since our upgrade to SL6/kernel 2.6.32. I guess previously that 32k was some sort of default or limit? Related to this was my query on when/how the (Linux) client may honour the preferred or optimal block size given in the FSINFO reply. Any ideas? Is it if a read of less than that preferred block size is requested then the preferred is used anyway because it comes at the same cost? Thanks, Jim > --b. > > > > > After the initial MOUNT request has been granted an FSINFO call is > > made. The contents of the REPLY from the server (another Linux > > 2.6.32 > > server) include rtmax, rtpref, wtmax and wtpref all of which are > > set > > to 1MB. This 1MB appears to come from that code/explanation I > > described earlier - all values are basically getting set to > > whatever > > comes out of nfsd_get_default_max_blksize(). > > > -- > 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 > -- Jim Vanns Senior Software Developer Framestore -- 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
