> rsize/wsize have in principle nothing to do with the blocksize that
> 'stat' returns. The f_bsize value specifies the 'optimal transfer
> block size'. Previously this has been set to the rsize/wsize, but when
> you add in O_DIRECT, then 32k becomes too large a value to align
> to. For this reason, the f_bsize value was changed to reflect the
> actual block size used by the *server*.
OK that explains the data with my own computer. But there is another case
when a Linux NFS client mounts an AIX NFS file system:
(preferred_blksize.perl shows s_blksize of stat() and is used due to the
non-existent stat command on this machine)
root@w0008077 / # mount -o hard,intr,nfsvers=3,udp,rsize=8192,wsize=8192
root@w0008077 / # ~xrsc062/preferred_blksize.perl /mnt/nmon7.tar
file /mnt/nmon7.tar has the preferred blksize 512.
root@w0008077 / # umount /mnt
root@ibm03 / # ~xrsc062/preferred_blksize.perl /net/ibm03/fs7/share/netinst_aix/nmon7.tar
file /net/ibm03/fs7/share/netinst_aix/nmon7.tar has the preferred blksize
As you can see, the actual server-side s_blksize is 4k, whereas the Linux
client takes it to be 512 bytes. An strace output confirms that a "cat" of
a file actually uses 512 byte IO chunks.
In each case the kernel used is a 2.4.20 with your NFS client patches (and
some of Neil's server patches).
If a RedHat or SuSE kernel is used (which probably does not include
O_DIRECT, but I am not sure) then there seems to be the correct behaviour,
and the s_blksize is the same as the rsize/wsize options demand, e.g. 8k
Many thanks in advance for your help and best regards.
Dr. Oliver Tennert
+49 -7071 -9457-598
science + computing AG
Hagellocher Weg 71
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 23 2003 - 22:00:29 EST