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>