On Wed, May 12, 2010 at 02:05:06PM +0200, Dag-Erling Sm??rgrav wrote: > Kostik Belousov <kostik...@gmail.com> writes: > > Dag-Erling Sm??rgrav <d...@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.
pgp7syKzzvjFV.pgp
Description: PGP signature
