[CentOS] Issues with stat() call on CentOS5 vs CentOS4
James Pearson
james-p at moving-picture.com
Mon Dec 13 15:30:09 UTC 2010
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
More information about the CentOS
mailing list