Hi,
I saw this line in fs/nfsd/nfs3xdr.c:
/* used */
p = xdr_encode_hyper(p, ((u64)stat->blocks) << 9);
It seems we are left-shifting the blocks 9 bits, to get the number of
bytes used. Is this a bug or we know the block size is always 512
bytes?
-Jidong
On 5 Dec 2022, at 0:44, Jidong Xiao wrote:
> Hi,
>
> I saw this line in fs/nfsd/nfs3xdr.c:
>
> /* used */
> p = xdr_encode_hyper(p, ((u64)stat->blocks) << 9);
>
> It seems we are left-shifting the blocks 9 bits, to get the number of
> bytes used. Is this a bug or we know the block size is always 512
> bytes?
By calling vfs_getattr(), which needs to behave for stat(2) syscall as
returning the number of 512 byte blocks. I think we're stuck with the
traditional idea that blocks are always 512 bytes in linux, at least from
the perspective of stat().
The history of such is beyond my time, but I don't think this is a bug.
Ben
On Mon, Dec 5, 2022 at 10:38 AM Benjamin Coddington <[email protected]> wrote:
>
> On 5 Dec 2022, at 0:44, Jidong Xiao wrote:
>
> > Hi,
> >
> > I saw this line in fs/nfsd/nfs3xdr.c:
> >
> > /* used */
> > p = xdr_encode_hyper(p, ((u64)stat->blocks) << 9);
> >
> > It seems we are left-shifting the blocks 9 bits, to get the number of
> > bytes used. Is this a bug or we know the block size is always 512
> > bytes?
>
> By calling vfs_getattr(), which needs to behave for stat(2) syscall as
> returning the number of 512 byte blocks. I think we're stuck with the
> traditional idea that blocks are always 512 bytes in linux, at least from
> the perspective of stat().
>
> The history of such is beyond my time, but I don't think this is a bug.
>
> Ben
>
I see. Thank you!
-Jidong