[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