Re: VOP_GETATTR: locking protocol change proposal

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Nov 18, 2011 at 06:31:21AM +0000, YAMAMOTO Takashi wrote:
 > >> postgresql assumes instant lseek(SEEK_END) to get the size of
 > >> their heap files.
 > >> 
 > >>   http://rhaas.blogspot.com/2011/11/linux-lseek-scalability.html
 > >> 
 > >> as fsync etc keeps the vnode lock during i/o, it might cause severe
 > >> performance regression.
 > > 
 > > I wonder if it is worth having a separate VOP for that, which would
 > > retrieve a subset of vattr without lock held.  There are potentially
 > > more uses in the tree.
 > 
 > while it's good to have VOP_GETATTR take a mask to specify a set of
 > requested attributes, i don't think it's worth to have a serparete VOP
 > for this.  (PR/30250 is related)
 > 
 > IMO we should make unlocked VOP calls safe (against revoke and umount -f)
 > and put VOP_GETATTR locking back into filesystem internal.

ad looked into that and concluded it was prohibitively expensive; too
much contention on every entry/exit.

Also, retrieving data protected by a particular lock without holding
it is inherently wrong; if we're going to move the file length out
from under the main vnode lock we'd better do it explicitly.

-- 
David A. Holland
dholland%netbsd.org@localhost