Re: VOP_GETATTR: locking protocol change proposal

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> 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.

what's "it"?

i agree naive reference counting on each VOP calls can be too expensive.

probably it's better to penaltize revoker's side.
eg. make revoke work on files etc instead of vnodes.
eg. have per-lwp "doing some VOPs" counter and make revoke check all of them.

> 
> 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.

i agree the protocol should be explicit.

YAMAMOTO Takashi

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