Messages in this thread | | | Date | Mon, 29 Sep 2003 22:23:45 -0700 | From | Frank Cusack <> | Subject | Re: effect of nfs blocksize on I/O ? |
| |
On Mon, Sep 29, 2003 at 01:27:51AM -0700, Trond Myklebust wrote: > >>>>> " " == Frank Cusack <fcusack@fcusack.com> writes: > > >> OTOH, bsize is of informational interest to programs that wish > >> to optimize I/O throughput by grouping their data into > >> appropriately sized records. > > > So then isn't the optimal record size 8192 for r/wsize=8192? > > Since the data is going to be grouped into 8192-byte reads and > > writes over the wire, shouldn't bsize match that? Why should I > > make 16x 512-byte write() syscalls (if "optimal" I/O size is > > bsize=512) instead of 1x 8192-byte syscall? > > Yes. It is already on my list of bugs. > > We basically need to feed 'wtpref' (a.k.a. 'wsize') into the f_bsize, > and 'wtmult' into f_frsize.
Then it sounds like the current wtmult/512 value for f_bsize is a bug. Until such time as you get f_frsize going, just directly plugging wsize into s_blocksize seems like a win. Doesn't it? At least, I don't see the advantage of using wtmult. (but could easily be missing it!)
> OTOH, the s_blocksize (and inode->i_blkbits) might well want to stay > with wtmult.
ISTM that f_frsize is pretty useless for NFS. Even if the server gives you this value (as wtmult), what use besides conversion of tbytes/abytes values does it have?
If you like, I can supply such a patch.
- s_blocksize, either . leave it as is (wtmult?wtmult:512) . set to wsize (ie, my first patch in this thread) - statfs, both . report wtpref as f_bsize (already done if s_blocksize = wsize) . report (wtmult?wtmult:wtpref) as f_frsize
I think the second s_blocksize option is better because not only statfs() but also stat() will use this value without any additional work.
/fc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |