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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC