Dear CentOS,
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.
[dougalb@centos4 tmp]$ cat my_stat.c #include <unistd.h> #include <stdio.h> #include <sys/stat.h> #include <sys/types.h>
int main(int argc, char **argv) { if(argc != 2) return 1;
struct stat fileStat; if(stat(argv[1],&fileStat) < 0) return 1;
printf("Block size: \t\t%d\n",fileStat.st_blksize);
return 0; }
[dougalb@centos4 tmp]$ [dougalb@centos4 tmp]$ gcc -o my_stat.exe my_stat.c [dougalb@centos4 tmp]$ [dougalb@centos4 tmp]$ ./my_stat.exe /mnt/nas/testfile Block size: 32768 [dougalb@centos4 tmp]$ [dougalb@centos4 tmp]$ cat /etc/redhat-release CentOS release 4.7 (Final) [dougalb@centos4 tmp]$
[dougalb@centos5 tmp]$ ./my_stat.exe /mnt/nas/testfile Block size: 4096 [dougalb@centos5 tmp]$ [dougalb@centos5 tmp]$ cat /etc/redhat-release CentOS release 5.5 (Final) [dougalb@centos5 tmp]$
On CentOS5 it is reporting 4k block sizes when it should report 32k. Has anyone seen this or aware of what is causing this change in behavior?
Kind regards,
Dougal
On 10/12/10 18:23, Dougal Ballantyne wrote:
Dear CentOS,
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.
[dougalb@centos4 tmp]$ cat my_stat.c #include<unistd.h> #include<stdio.h> #include<sys/stat.h> #include<sys/types.h>
int main(int argc, char **argv) { if(argc != 2) return 1;
struct stat fileStat; if(stat(argv[1],&fileStat)< 0) return 1; printf("Block size: \t\t%d\n",fileStat.st_blksize); return 0;}
[dougalb@centos4 tmp]$ [dougalb@centos4 tmp]$ gcc -o my_stat.exe my_stat.c [dougalb@centos4 tmp]$ [dougalb@centos4 tmp]$ ./my_stat.exe /mnt/nas/testfile Block size: 32768 [dougalb@centos4 tmp]$ [dougalb@centos4 tmp]$ cat /etc/redhat-release CentOS release 4.7 (Final) [dougalb@centos4 tmp]$
[dougalb@centos5 tmp]$ ./my_stat.exe /mnt/nas/testfile Block size: 4096 [dougalb@centos5 tmp]$ [dougalb@centos5 tmp]$ cat /etc/redhat-release CentOS release 5.5 (Final) [dougalb@centos5 tmp]$
On CentOS5 it is reporting 4k block sizes when it should report 32k. Has anyone seen this or aware of what is causing this change in behavior?
What kind of network file system is used to mount your NAS?
kind regards,
David Sommerseth
Hi David,
I am using NFSv3. Sorry, should have said that!
-Dougal
On Fri, Dec 10, 2010 at 2:06 PM, David Sommerseth dazo@users.sourceforge.net wrote:
On 10/12/10 18:23, Dougal Ballantyne wrote:
Dear CentOS,
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.
[dougalb@centos4 tmp]$ cat my_stat.c #include<unistd.h> #include<stdio.h> #include<sys/stat.h> #include<sys/types.h>
int main(int argc, char **argv) { if(argc != 2) return 1;
struct stat fileStat; if(stat(argv[1],&fileStat)< 0) return 1;
printf("Block size: \t\t%d\n",fileStat.st_blksize);
return 0; }
[dougalb@centos4 tmp]$ [dougalb@centos4 tmp]$ gcc -o my_stat.exe my_stat.c [dougalb@centos4 tmp]$ [dougalb@centos4 tmp]$ ./my_stat.exe /mnt/nas/testfile Block size: 32768 [dougalb@centos4 tmp]$ [dougalb@centos4 tmp]$ cat /etc/redhat-release CentOS release 4.7 (Final) [dougalb@centos4 tmp]$
[dougalb@centos5 tmp]$ ./my_stat.exe /mnt/nas/testfile Block size: 4096 [dougalb@centos5 tmp]$ [dougalb@centos5 tmp]$ cat /etc/redhat-release CentOS release 5.5 (Final) [dougalb@centos5 tmp]$
On CentOS5 it is reporting 4k block sizes when it should report 32k. Has anyone seen this or aware of what is causing this change in behavior?
What kind of network file system is used to mount your NAS?
kind regards,
David Sommerseth
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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
James,
Thank you. This is very helpful. It does seem like a very strange change in behavior between CentOS/RHEL4,5 & 6.
I am rebuilding a kernel with only i_blksize restored for NFS. Don't like having to change the kernel but might be needed to keep consistency accross releases.
-Dougal
On Mon, Dec 13, 2010 at 9:30 AM, James Pearson james-p@moving-picture.com wrote:
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 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Dougal Ballantyne wrote:
James,
Thank you. This is very helpful. It does seem like a very strange change in behavior between CentOS/RHEL4,5 & 6.
I am rebuilding a kernel with only i_blksize restored for NFS. Don't like having to change the kernel but might be needed to keep consistency accross releases.
Maybe you should open a Bugzilla report with Red Hat?
James Pearson
-
David Sommerseth -
Dougal Ballantyne -
James Pearson