On Fri, Dec 14, 2018 at 6:44 PM Bryan Henderson
wrote:
> > Going back through the logs though it looks like the main reason we do a
> > 4MiB block size is so that we have a chance of reporting actual cluster
> > sizes to 32-bit systems,
>
> I believe you're talking about a different block size
Bryan Henderson :
> 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
> 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
> Going back through the logs though it looks like the main reason we do a
> 4MiB block size is so that we have a chance of reporting actual cluster
> sizes to 32-bit systems,
I believe you're talking about a different block size (there are so many of
them).
The 'statvfs' system call (the
On Fri, Dec 14, 2018 at 7:50 AM Bryan Henderson wrote:
>
> I've searched the ceph-users archives and found no discussion to speak of of
> Cephfs block sizes, and I wonder how much people have thought about it.
>
> The POSIX 'stat' system call reports for each file a block size, which is
> usually
On Thu, Dec 13, 2018 at 3:31 PM Bryan Henderson
wrote:
> I've searched the ceph-users archives and found no discussion to speak of
> of
> Cephfs block sizes, and I wonder how much people have thought about it.
>
> The POSIX 'stat' system call reports for each file a block size, which is
>
I've searched the ceph-users archives and found no discussion to speak of of
Cephfs block sizes, and I wonder how much people have thought about it.
The POSIX 'stat' system call reports for each file a block size, which is
usually defined vaguely as the smallest read or write size that is