Messages in this thread | | | Date | Tue, 9 Mar 1999 15:36:05 -0500 (EST) | From | Erez Zadok <> | Subject | Re: NFS client performance 1.5 orders of magnitude too slow? (fwd) |
| |
In message <m10KTko-0007U1C@the-village.bc.nu>, Alan Cox writes: > > b) is this another "wsize" issue. How do I get amd to mount an fs with > > wsize=8192 (given that I don't control and therefore cannot change > > the NIS maps amd reads?) > > Its a "NFS client" thing. The write gathering patches in 2.2.2ac7 fix > this but they aren't quite ready for the mainstream just yet - but are > very close
Does that mean that the behavior of rsize/wsize in newer kernels will change? Or the default 4k change?
On a related note: the default behavior of recent linux kernels when the rsize/wsize is set to 0 (i.e., undefined) in the struct nfs_mount_data is to use NFS_DEF_FILE_IO_BUFFER_SIZE which is 4k now? Perhaps amd should not force the value of the rsize/wsize that's passed in nfs_mount_data, but rather let the kernel set it (unless an amd user specified rsize=X or wsize=Y in their maps).
But since when did this linux kernel behavior start? If I make amd just set the rsize/wsize fields to 0, would it break things for older kernels? I'd think it'd be better for amd to let the running kernel set these options internally, I just need to know what kernel versions have different behavior that may need some intervening on amd's part.
I don't want to hard-code this value from <linux/nfs_fs.h>, b/c that way I can build one amd binary that can run on older and newer kernels.
Erez.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |