Date: Fri, 5 May 1995 23:08:09 +1000 From: Bruce Evans <bde@zeta.org.au> To: ted@wiz.plymouth.edu, terry@cs.weber.edu Cc: freebsd-bugs@freefall.cdrom.com Subject: Re: bin/381: Quota commands (repquota/edquota/quota) not giving correct info. Message-ID: <199505051308.XAA22331@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> edquota, repquota & quota not reporting blocks of quota correctly, >> always reporting incorrect information including an (NULL) under >> the Warning info part of 'quota'. >[ ... ] >> > dbtob(qup->dqblk.dqb_curblocks) / 1024, >> > dbtob(qup->dqblk.dqb_bsoftlimit) / 1024, >> > dbtob(qup->dqblk.dqb_bhardlimit) / 1024); >I think the 1024's here should be the manifest constant for block size... No, I think the 1024 here is just for reporting the size in units of 1K. The block size conversion is done in dbtob() using appropriate manifest constants. I activated this bug when I partially fixed file systems with size >= 4GB. dbtob() used to have type `unsigned'. Now it has type `unsigned long long' (perhaps it should have type `long long'; I was confused about the type of daddr_t when I fixed it, but apparently the authors or quota.h were too - the block limits have the sensible type `unsigned long'). A long long type is required for holding file sizes. Block numbers are 31 bits on i386's and DEV_BSIZE is usually 512 so 40 bits would usually be sufficient. The bug is that edquota.c expects to print the above values (which have the unknown/undocumented type of dbtodb()) using %d format. The suggested fix replaces the scaling of `x = (x << 9) / 1024' by `x = x / 2'. This has too much magic and assumes that %d is suitable for printing things of type `unsigned long'. The correct fix is probably to cast the values to `unsigned long' and print them in format %lu. The overhead of doing calculations involving quads is probably unimportant here. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505051308.XAA22331>