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