HEADS UP: 64-bit quotas going in to head today

Kostik Belousov kostikbel at gmail.com
Wed May 12 12:16:03 UTC 2010


On Wed, May 12, 2010 at 02:05:06PM +0200, Dag-Erling Sm??rgrav wrote:
> Kostik Belousov <kostikbel at gmail.com> writes:
> > Dag-Erling Sm??rgrav <des at des.no> writes:
> > > It adds quite a bit of code to pretty much every UFS VOP.
> > No, it does not. Essentially, it adds one or two function calls per
> > vop that allocate or deallocate blocks or inodes, and the function
> > bodies verify two array members and return if those are NULL.
> 
> Read ufs_vnops.c, count the number of #ifdef QUOTA.  There's quite a bit
> more than just "one or two function calls per vop".  Quite a bit of
> locking going on, too, e.g. in ufs_accessx().

I did read the code when I fine-locked quotas. I stand on my position
that it is one or two accounting calls per vop that do nothing in case
of disabled quotas.

ufs_accessx() path is seldomly executed. You mostly have to open file
read-write if you are going to modify inode, and vn_open_cred() already
uses exclusive locking there. It is calls like chmod(2) that are catched
at this point, performing the operation by path instead of fd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100512/2a5a125b/attachment.pgp


More information about the freebsd-current mailing list