> I tested fread on Fedora 28. fread does 8k read on even block size is 4M.
So maybe I should be looking at changing my GNU Libc instead of my Ceph.
But I can't confirm that reading 8K regardless of blocksize is normal anywhere.
My test on Debian 9 (about 3 years old) with glibc 2.24 shows fread causes a
blocksize read. Same on a system with Glibc 2.19.
I'm using the 'stat' program from Coreutils to see the blocksize and using
strace of a program that does a fopen and a 4-byte fread to see the read size.
Here is the code from Glibc 2.23 as well as current development where it
appears to be designed to use the blocksize if it has one:
size = _IO_BUFSIZ;
if (fp->_fileno >= 0 && __builtin_expect (_IO_SYSSTAT (fp, &st), 0) >= 0)
{
if (S_ISCHR (st.st_mode))
{
...
}
#if _IO_HAVE_ST_BLKSIZE
if (st.st_blksize > 0)
size = st.st_blksize;
#endif
}
p = malloc (size);
...
_IO_setb (fp, p, p + size, 1);
_IO_BUFSIZ above is 8K, so I expect an 8K read if the stat fails or reports no
blocksize (st_blksize == 0).
The fread code in glibc reads the full size of the buffer allocated by the
above code, as recorded by that _IO_setb call.
[_IO_file_doallcate() in libio/filedoalloc.c]
> NFS reports 1M block size
Can't reproduce that one either.
In some NFS experiments of mine, the blocksize reported by 'stat' appears to
be controlled by the rsize and wsize mount options. Without such options, in
the one case I tried, Linux 4.9, blocksize was 32K. Maybe it's affected by
the server or by the filesystem the NFS server is serving. This was NFS 3.
> This patch should address this issue [massive reads of e.g. /dev/urandom]:.
Thanks!
> mount option should work.
And thanks again.
--
Bryan Henderson San Jose, California
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
