9:05 a.m.
RQUOTA is very old, and was never documented in an RFC. The canonical
documentation is the rquota.x file that was shipped with Sun RPC. That
defines these fields as 32-bit unsigned integers, so there's nothing we
can do about it in Ganesha.
NFSv4 has quota limits in it, that are 64-bit integers. I suspect that,
if you're dealing with sizes like 4T, nfsv3 is too old, and you're
better off switching to NFSv4.
Daniel
On 2/22/21 8:03 PM, Frank Filz wrote:
> So I see a discrepancy in the size of the structures representing
quota sizes.
> Consider
>
> struct rquota {
> int rq_bsize;
> bool_t rq_active;
> u_int rq_bhardlimit;
> u_int rq_bsoftlimit;
> u_int rq_curblocks;
> u_int rq_fhardlimit;
> u_int rq_fsoftlimit;
> u_int rq_curfiles;
> u_int rq_btimeleft;
> u_int rq_ftimeleft;
> };
>
> They are all 4-byte structures (on most systems). Now, if you look at
> include/fsal_types.h, they are explicitly defined as 8-byte unsigned.
>
> typedef struct fsal_quota__ {
> uint64_t bhardlimit;
> uint64_t bsoftlimit;
> uint64_t curblocks;
> uint64_t fhardlimit;
> uint64_t fsoftlimit;
> uint64_t curfiles;
> uint64_t btimeleft;
> uint64_t ftimeleft;
> uint64_t bsize;
> } fsal_quota_t;
>
> As a result, in rquota_getquota(), when you copy the values from the latter
> (obtained from underlying fsal) into the former, loss of bits might occur. We are
> currently seeing this for a customer with a 1024 block size and 4T quota. Do you
> know if there's a reason (RFC specifications or such) that cause the former to
be
> 32-bytes and if not, would it be OK to increase it?
The RQUOTA protocol is old, so it may well be defined as 32 bit quantities. Ganesha QUOTA
support needs some work, I know it also doesn't handle sub-mounted filesystems
correctly either.
Frank
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org