Dougal Ballantyne wrote:
I have recently upgraded several servers from CentOS4 to CentOS5 and I am noticing a strange change to the stat() call. I have written a very small program to test and show the behavior. I am calling stat() against a file which is exported from my NAS and mounted with 32k read/write sizes.
The man page for stat(2) states:
Use of the st_blocks and st_blksize fields may be less portable. (They were introduced in BSD. The interpretation differs between systems, and possibly on a single system when NFS mounts are involved.)
Also, the kernel patch at http://android.git.kernel.org/?p=kernel/common.git;a=commitdiff_plain;h=ba52de123d454b57369f291348266d86f4b35070 states:
This eliminates the i_blksize field from struct inode. Filesystems that want to provide a per-inode st_blksize can do so by providing their own getattr routine instead of using the generic_fillattr() function.
Note that some filesystems were providing pretty much random (and incorrect) values for i_blksize.
The CentOS5 kernel contains the above patch, which removes the setting of st_blksize by the NFS client kernel code - previously, the NFS client code set st_blksize to the wsize (write size)
The default for blksize is PAGE_CACHE_SIZE (in fs/stat.c) - which is 4096
However, with CentOS6/RHEL6, it appears st_blksize has reverted back to wsize - the default is now (in fs/stat.c) "1 << inode->i_blkbits"
As a test, I rebuild a CentOS5 kernel with the above change - and stat() now reports the wsize for st_blksize ...
I don't know if this is a bug or a feature
James Pearson