On 10/27/07, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote: > Hi, > > I had me a little look at bdi usage in networked filesystems. > > NFS, CIFS, (smbfs), AFS, CODA and NCP > > And of those, NFS is the only one that I could find that creates > backing_dev_info structures. The rest seems to fall back to > default_backing_dev_info. > > With my recent per bdi dirty limit patches the bdi has become more > important than it has been in the past. While falling back to the > default_backing_dev_info isn't wrong per-se, it isn't right either. > > Could I implore the various maintainers to look into this issue for > their respective filesystem. I'll try and come up with some patches to > address this, but feel free to beat me to it. I would like to understand more about your patches to see what bdi values makes sense for CIFS and how to report possible congestion back to the page manager. I had been thinking about setting bdi->ra_pages so that we do more sensible readahead and writebehind - better matching what is possible over the network and what the server prefers. SMB/CIFS Servers typically allow a maximum of 50 requests in parallel at one time from one client (although this is adjustable for some). The CIFS client prefers to do writes 14 pages (an iovec of 56K) at a time (although many servers can efficiently handle multiple of these 56K writes in parallel). With minor changes CIFS could handle even larger writes (to just under 64K for Windows and just under 128K for Samba - the current CIFS Unix Extensions allow servers to negotiate much larger writes, but lacking a "receivepage" equivalent Samba does not currently support larger than 128K). Ideally, to improve large file copy utilization, I would like to see from 3-10 writes of 56K (or larger in the future) in parallel. The read path is harder since we only do 16K reads to Windows and Samba - but we need to increase the number of these that are done in parallel on the same inode. There is a large Google Summer of Code patch for this which needs more review. -- Thanks, Steve - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
