Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Jun 2008 17:43:44 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: It's 2008.  1 TB disk drives cost $160.  Quotas are 32-bit.
Message-ID:  <20080629174039.Q20262@fledge.watson.org>
In-Reply-To: <20080629123733.GO17123@deviant.kiev.zoral.com.ua>
References:  <20080628132632.R1807@kozubik.com> <20080628235832.GA15910@eos.sc1.parodius.com> <20080629123733.GO17123@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080629174039.Q20262>