It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit.

[Robert Watson]

On Sun, 29 Jun 2008, Kostik Belousov wrote:

> The change alone of the 32/31-bit fields in the struct dqblk to the 64-bit 
> is a trivial part. I think in-kernel part would simply work after the 
> conversion, but I have no idea about user-mode utilites. Most likely, 
> usermode would require some tweaking.
>
> Not so easy is the backward compatibility. Quota file is read/written 
> directly by the kernel, and have no useful magic sequence to identify it. 
> Some external measures are needed to inform kernel about the version of the 
> dqblk on the disk. Then, either code shall be conditionalized to do the 
> keeping in 32/64 bitness (preferrable), or old dqblk layout shall be 
> converted from/to on i/o.
>
> Another useful thing to do with in-kernel quota implementation is to move it 
> from ufs/ to the generic VFS service. Again, the code is mostly 
> filesystem-neutral, and the change should be in the interfaces. This would 
> make addition of the quota support for some non-ufs filesystems nearly 
> trivial.

Quite, and compatibility needs to be done fairly carefully to prevent some 
rather awkward foot-shooting that might otherwise take place.  One possibility 
might be to have a header the size of the existing dqblk and store a magic 
value (perhaps in the negative range) in one or both of the two signed int 
fields (dqb_btime and dqb_itime).  Other than this one issue, updating to 
64-bit support should really be no problem, and as the reporter points out, is 
long-overdue.

FWIW, that "make it a library" change would be very similar to what we've done 
for ACLs, where there are central vfs_acl.c and subr_acl_posix1e.c which 
represent common system call code, and a library to be used by file systems in 
implementing ACLs to avoid duplicated code.  I think Apple may already have 
made this change for quotas as well, btw.

Robert N M Watson
Computer Laboratory
University of Cambridge