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